RE: symbolic debug of loadable modules with kgdb light

[Caz Yokoyama <cazyokoyama at gmail dot com>]

Hello,
Did you happen to try the former extension with the QEMU or KVM backend
already? 
---
No. I am glad if you tell me how to do that. I saw a paper which talked
about running kgdb for guest OS of Xen.
(http://www.kernel.org/doc/ols/2006/ols2006v2-pages-9-24.pdf). I know there
is serial console in Virtual Machine Manager, i.e. select Guest OS ->
Details -> view -> serial console. But I have no idea how to connect it.

Is it possible to disable the SysRq interrupt for this use case?
----
I am not clear your point. My modification uses SysRq. I mean there are two
ways to generate SysRq, 1) from keyboard and 2) from serial port. 1) is
obvious, i.e. hit Ctrl+Alt+SysRq + g. 2) is BREAK and g. When my modified
gdb is invoked, it sends BREAK and g which break-in to kernel. Did I answer
your question? Or are you asking something else?
-caz

-----Original Message-----
From: jan.kiszka@web.de [mailto:jan.kiszka@web.de] 
Sent: Friday, January 09, 2009 3:11 AM
To: Caz Yokoyama
Cc: gdb@sourceware.org
Subject: Re: symbolic debug of loadable modules with kgdb light

Caz Yokoyama wrote:
> Hello,
> I started a sourceforge project called kgdb-light
> (http://sourceforge.net/projects/kgdb-light/). kgdb-light is a modified
gdb
> which handles symbol tables of loadable modules of Linux kernel 2.6.26 and
> later. Linux kernel 2.6.26 and later integrates kernel debugging under
> kernel hacking. Gdb handles symbol table of Linux kernel, but it does not
> for loadable modules. Kgdb-light updates internal symbol table by reading
> "struct module" in kernel. I also modified gdb to send Magic SysRq,
> therefore, target may locate far away.
> 

Sounds very interesting. Did you happend to try the former extension
with the QEMU or KVM backend already? Would be _very_ cool if such
support became mainline (I'm tired of add-symbol-file with manually
looked-up module addresses...). Is it possible to disable the SysRq
interrupt for this use case? [ I still consider this variation of the
original remote protocol an unfortunate decision of the kernel
developers, but back then I wasn't able to convince them to change it. ]

Jan