Whilst recently trying to understand the context of a lock up involving
mach-defpager, I became frustrated by the missing functionality to
display function arguments within the 64 bit gnumach debugger. I'm aware
that this is a complex problem since most of those argument values are
managed as register state rather than the stack. I started to write code
to parse the Dwarf debug content as it seemed like an interesting
digression. Only when I got as far as working out how to traverse the
stack history to recover argument values in other frames did I stop to
consider whether this was indeed the right approach.
I can see that even a minimal parsing of the Dwarf content would require
quite a lot of code and it doesn't seem like the "Hurd way" to add so
much to the kernel even if it can be compiled out for non-developers.
Nevertheless, gnumach debugger does support breakpoints etc. so it would
surely be expected to at least view the function arguments. But taken to
an extreme, the thought of embedding a reimplementation of gdb within
gnumach seems wrong. What is the appropriate balance here?
Might it be possible instead to make gdb "gnumach aware" somehow through
use of a gdb plugin or similar? That would be realistic for virtual
machines using Qemu but perhaps not so much for real hardware using a
serial port. Are serial ports even available for real machines these days?
I was rather enjoying learning about Dwarf but I can see that it might
not be a good use of my time. Any thoughts on this issue are welcome.
Cheers,
Mike.
- 64 bit gnumach KDB stack traces Michael Kelly
-
