Hi João:
That's a lot of questions I'll try to give you my perspective on them: > Thanks for your answer. From the above paragraph, I deduce that is indeed > possible (with KGDB) to debug not only the target kernel, but also the > target's applications. Is that right? You can easily debug the kernel but target applications are not easy. The PC and the stack pointer for the user process are not Likely saved on the users stack but on a kernel stack for the process. The process should be mapped while your trapping into The kernel but the user is using virtual addresses so you won't be able to walk the stack. About all you can do is use the PC, Convert it to an address that the kernel can access and look at the code causing the exception. I'm a bit guessing here that Kgdb can access memory the same as we did on Xtensa with JTAG debugging with gdb. > I've searched all over Google, but as I've mentioned previously the > documentation doesn't refer the (im)possibility of this scenario. Right, it's difficult, likely an expensive JTAG setup like from ARM has additional code to do the mappings for user space. A program like crash could do these kind of mappings. > From using KGDB / GDB empirically, I understand that I can run GDB on the > target and control it remotely on the host (via the terminal emulator while > the > target system is running, i. e. KGDB isn't enabled), but this seems to > be a strange and unreliable way to do it (alternating between KGDB and GDB). > Am I thinking correctly? I used the KGDB stub in the kernel and gdb on my workstation and at the same time ran gdb on the target. For both HPUX and Xtensa it was necessary to detach from KGDB for gdb to work. Usually the KGDB and The target's gdb are using the same breakpoint instructions and breakpoints for the target gdb get to the KGDB Stub, which isn't helpful at all. > 1 - Breakpoints accept physical addresses or virtual addresses? I'm pretty sure that they are always virtual. The kernel and the application are compiled with virtual addresses; So it's really only useful to use virtual addresses when placing breakpoints. I did use breakpoints with JTAG while Initializing the mapping of the MMU and had add some linker commands to allow my starting the debug with one Set of virtual addresses and continue debugging as the code switched to another mapping. On Xtensa we were Using three different mappings for the same code and we initialized the MMU. > 2 - I know it's possible to change the value of a register with the "set" > command. It is also possible to change an instruction (code segment)? And > what about a data segment (memory zone)? Yes, it's a bit awkward, as I recall you use a write gdb command. Gdb may still need to be started with a -w option to allow writing on the text section. Also the kernel text can be configured R/O and you likely need a later version of KGDB to poke thru or just reconfigured the kernel text to not be mapped Read only. > 3 - Let's assume that I set a breakpoint in a certain line of code, on a C > file. Since that line will certainly be transformed into > several assembly lines by the compiler, how will I know in which assembly > line the breakpoint will really be? In other words, > what's the granularity of KGDB / GDB breakpoints? The break instructions on Xtensa were very small, granularity wasn't a problem. You can relate breakpoints in C and asm code easily with DDD and enable the asm language window. > I'm still reading the documentation for both debuggers > (https://sourceware.org/gdb/onlinedocs/gdb/index.html and > https://www.kernel.org/pub/linux/kernel/people/jwessel/kgdb/), > so let's see if I have any luck on the meantime. > I'm assuming these are the best sources of documentation, > but if you know other valuable resources I'd appreciate if you can share it > with me. > Also, if you know the answer to any of the questions above, that would be > awesome. Yes your web references sound current, I've finding the documentation on using the keyboard Early debug mechanism difficult. I haven't been able to get the PS2 to DB9 connection Working and on our servers we don't have a PS2/keyboard interface and I would like To start debugging as soon as with the 'ekgdboc=kbd' boot option. There is also: https://www.kernel.org/doc/htmldocs/kgdb/EnableKGDB.html there is also the kgdb mailing list: http://sourceforge.net/p/kgdb/mailman/kgdb-bugreport/ and comments is the kgdb code: git clone https://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git Hope that answered some of your questions João. -piet > I've never found KGDB or JTAG debugging very useful for user space > applications. > On Xtensa, with JTAG and GDB, we did use the PC and a bit of the > context is user space to understand The context of a TLB miss. That > was a bit helpful for cache alias issues. Hello Pete, Thanks for your answer. From the above paragraph, I deduce that is indeed possible (with KGDB) to debug not only the target kernel, but also the target's applications. Is that right? I've searched all over Google, but as I've mentioned previously the documentation doesn't refer the (im)possibility of this scenario. From using KGDB / GDB empirically, I understand that I can run GDB on the target and control it remotely on the host (via the terminal emulator while the target system is running, i. e. KGDB isn't enabled), but this seems to be a strange and unreliable way to do it (alternating between KGDB and GDB). Am I thinking correctly? Also, while experimenting with KGDB / GDB, more doubts emerged. If it's not too much, I would like to know if: 1 - Breakpoints accept physical addresses or virtual addresses? 2 - I know it's possible to change the value of a register with the "set" command. It is also possible to change an instruction (code segment)? And what about a data segment (memory zone)? 3 - Let's assume that I set a breakpoint in a certain line of code, on a C file. Since that line will certainly be transformed into several assembly lines by the compiler, how will I know in which assembly line the breakpoint will really be? In other words, what's the granularity of KGDB / GDB breakpoints? I'm still reading the documentation for both debuggers (https://sourceware.org/gdb/onlinedocs/gdb/index.html and https://www.kernel.org/pub/linux/kernel/people/jwessel/kgdb/), so let's see if I have any luck on the meantime. I'm assuming these are the best sources of documentation, but if you know other valuable resources I'd appreciate if you can share it with me. Also, if you know the answer to any of the questions above, that would be awesome. Thanks for reading, all the best, João > > ARM has a $100,000 Corsight debugger which has the ability to profile > both the Kernel and user space applications; perhaps debugging the > application was also supported; Ir was pretty slick. > > Perhaps that demo was done on a M-series Chip. At an ARM lecture they > mentioned that the M-series handles Exception In a why which is > compatible with the C-ABI. This makes it so that exceptions can be > Back-traced with gdb; perhaps even across the user-space to kernel > exceptions. > > -piet > > -- > Pete/Piet Delaney > O: +1 408 935-1813 > C: +1 408 646-8557 > H: +1 408 243-8872 > Home Email: piet.dela...@gmail.com<mailto:piet.dela...@gmail.com> > > > > > -----Original Message----- > From: joaoandrefe...@sapo.pt<mailto:joaoandrefe...@sapo.pt> > [mailto:joaoandrefe...@sapo.pt] > Sent: Monday, October 20, 2014 9:26 AM > To: > kgdb-bugreport@lists.sourceforge.net<mailto:kgdb-bugreport@lists.sourceforge.net> > Subject: [Kgdb-bugreport] Can KGDB also debug applications? > > Hello all, again, > > I'm using KGDB to interrupt and debug the linux kernel on a target > machine, and I'm noq wondering if I can do the same at application > level, i.e. interrupt / debug a application (not a kernel module) of > my choice, that would be running on the target machine. I know that > supposedly GDB is intended to debug applications and KGDB the kernel, > but this is a feature that quite I'm interested in, and despite the > intensive search, I haven't reached a conclusion. What I found was the > mention of the typical scenarios where GDB debugs applications, and > KGDB the kernel. > > Thanks for reading, > João > > ---------------------------------------------------------------------- > -------- Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Kgdb-bugreport mailing list > Kgdb-bugreport@lists.sourceforge.net<mailto:Kgdb-bugreport@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport ------------------------------------------------------------------------------ _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
