Re: kernel debugging question

[Sascha Wildner <saw@xxxxxxxxx>]

Matthew Dillon wrote:

>     You can actually run gdb on a live kernel like this:
>
>     gdb -k /dev/mem /path/to/kernel.debug

It's the other way round here:

gdb -k /path/to/kernel.debug /dev/mem

:)


>     You can then use the 'proc' command to switch to a process (give it a
>     pid), and do a stack backtrace.  That part only really works if the
>     process is blocked on something (i.e. not running).
>
>     But you can also dig around kernel globals and various data structures
>     and that can be quite useful on a live system.

My problem is that I want to take a look at what's happening during 
console initialization, i.e. when init386() calls cninit() in machdep.c.

I started with putting printfs into syscons code. Then it dawned upon me 
that printf() is probably not yet working at the stage I was interested 
in (values that should've been 0 were already initialized in my printf 
output and so on).

So I thought serial debugging would be the way to go until I found that 
console initialization is done before the debugger comes into play 
(well, of course it is). D'oh! :)

The only way I can think of now is to create global data that I can look 
at after Debugger() has been called (in fact, this is what I'm going to 
do next). Question was, is there a better/more elegant way?

But it was interesting so far, I learned a few things, set up serial gdb...

Regards,
Sascha

--
http://yoyodyne.ath.cx