[haiku-gsoc] Re: Kernel GDB stubs
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Fri, 03 Jun 2011 15:32:32 +0200
On 2011-06-03 at 06:15:21 [+0200], Mike Smith <scgtrp@xxxxxxxxx> wrote:
> > After staring the gdb command it acts as a debug stub for gdb. You have
> > to connect gdb to it via serial line. Check the gdb documentation how to
> > do that. IIRC it's something like a "remote" command or setting. I
> > believe you can even get the KDL prompt back somehow (check the sources
> > -- maybe it's even just by disconnected gdb). Last time I checked, it
> > wasn't possible to load a Haiku kernel built with gcc 2 and debug info in
> > any gdb I tried (both Haiku's and several version under Linux). They all
> > either crashed or hung. With the gcc 4 kernel it worked fine, though.
>
> I attempted to set this up by having VBox connect the serial port to a
> pipe instead of a file, and managed to get gdb to connect to it with
> some socat hackery, but gdb seems incapable of understanding the
> protocol Haiku is speaking:
No, this looks more like a different problem. Since the serial port is also
used for debug output, you must make sure that you don't connect gdb before
you have started the gdb KDL command. Furthermore, if the serial "device"
you're using is buffered (not sure whether that happens with your pipe +
socat combo), you have to empty the buffer first (by reading it). I just
tested with both qemu's "pty" and "tcp" serial devices and they do work in
principle, save for the fact that a while ago I apparently broke the "g"
command (reading registers), so that connecting fails anyway (with "E01").
I'll try and have a quick look, whether I can fix that without too much
effort.
Other than that, you need to provide the kernel executable as parameter to
gdb, so it knows where to look for symbols and debug info. Note that kernel
add-ons are not automatically recognized/found by gdb. I don't know whether
gdb has a command to explicitly specify that a certain shared object has been
loaded at a certain address. Only if there is, you'll have a chance of
getting a nice info for the respective parts of the stack trace. And finally,
stack traces won't be usuable beyond interrupt frames, since gdb doesn't know
about those. Did I mention that the gdb support is really rudimentary? ;-)
CU, Ingo
Other related posts:
