lkml.org 
[lkml]   [2015]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH] scripts/gdb: add data window feature
From
2015-07-22 5:04 GMT+08:00 Jan Kiszka <jan.kiszka@web.de>:
> On 2015-07-16 17:58, Houcheng Lin wrote:
>> Add data window feature to show current kernel status
>> on separate consoles, including: 1) registers, 2) back
>> trace and 3) watch data windows.
>>
>> The data window would help kernel developer to understand
>> current hardware/ kernel status, and on single-stepping, the
>> modified fields in the data window would be highlighted.
>
> I was trying to get an overview of this feature. Unfortunately, it does
> not work for me. I type in the commands you describe in the
> documentation, but nothing shows up. I suspect there are some hard-coded
> assumption about directory layouts etc. that aren't fulfilled here
> (out-of-tree build).
Sorry for not working. The steps might be run the "lx-dw" command
first, then step the kernel in gdb; the kernel status would be dump
to files in /tmp. Then you can run lx-dw.sh that creates 3 xterm window
to display registers, back trace and watch variables.

>
> Anyway, let's try to understand what you would like to achieve. This
> seems to be some add-on tool for gdb debugging sessions to display
> target states continuously in separate terminals. Right? Is this
> comparable to gdb's tui mode?
>
Yes, it is similar feature; dumps the content of register and kernel
status into a separate window continuously and highlight the difference.
It's snapshot is here:
https://www.dropbox.com/s/tl67sxm6474jd8i/dw-screenshot.png?dl=0

> More important, is this specific to the debugging infrastructure we have
> in scripts/gdb? Or could I install it (after some modifications, I
> guess) in my home directory and use it for any gdb session, not just
> with Linux kernels? Is there anything in it that particularly refers to
> Linux structures? In that case I would suggest to make it stand-alone
> first so that one could easily include it whenever needed, either
> explicitly or via ~/.gitinit.

This is not under the infrastructure of kernel gdb, however, this feature
is needed and specific for kernel debugging. When trace an optimized kernel
source, we usually need to trace it in assembly and throught the data window
to update the current kernel status. It can be standalone, but I think it may
helps a lot when developing kernel and good to be part of kernel gdb scripts.

best regards,
Houcheng Lin

>
> Thanks for sharing in any case!
>
> Jan
>



--
Best regards,
Houcheng Lin


\
 
 \ /
  Last update: 2015-07-22 04:01    [W:0.039 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site