2015-07-22 5:04 GMT+08:00 Jan Kiszka <jan.kiszka@xxxxxx>: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html