[haiku-development] Re: Jamming in debugging info?
- From: pete.goodeve@xxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 13 Jul 2009 18:20:54 -0700
On Tue, Jul 14, 2009 at 02:08:47AM +0200, Ingo Weinhold wrote:
>
> -------- Original-Nachricht --------
> > Datum: Mon, 13 Jul 2009 16:06:52 -0700
> > Von: pete.goodeve@xxxxxxxxxxxx
>
> > I'm still looking at the usb_midi code, and one of the problems is
> > a frequent -- but seemingly random -- KDL in the USB callback function.
> > I'd like to be able to establish exactly which action in the code is
> > causing it, and that would be easier if I could connect the hex offset
> > to a line of code (with objdump probably). However, the default
> > compilation
> > doesn't put any debugging data in the object, and I can't see how to get
> > it in.
> >
>
> Please have a look at build/jam/UserBuildConfig.ReadMe. Searching for DEBUG
> will turn up the info you're looking for.
Thanks, but I'm still not quite clear... From my reading of the Jam manual
(http://public.perforce.com/public/jam/src/Jam.html) I gather that 'debug'
as far as Jam is concerned refers to levels of Jam error messaging, not
control of the info in the binaries. Searching for 'DEBUG' in the file
you suggest only seems to turn up those.
I do see that one can set CCFLAGS and so on -- is that actually where
I should do it?
>
> Regarding displaying the line number information, readelf can help:
>
> readelf --debug-dump=decodedline <file>
Thanks -- I'll check into that.
>
> Note that save for the kernel respectively a program shared objects are not
> loaded at the addresses recorded in the file, though. For kernel modules you
> can use the "image" command in KDL (without parameter to get a list, with ID
> as parameter to get details) or "listimage" in the command line to get the
> info for the address difference.
Is this important? In the KDL display, the fault is shown at
"midi_usb_callback+0x177", so I don't think I'm concerned with absolute
addresses at all. (It's a vm_page_fault, incidentally, which seems a
bit odd in code that should be entirely kernel space.)
-- Pete --
Other related posts:
