Making GDB recognize the Haskell DWARF source language ID

Joel Brobecker
Wed Mar 5 15:16:00 GMT 2014

> Here's a (short) example session. There are actually two problems here:
>   #2  0x00000000004047a0 in Main_zdwfibzuerr_info () at stack-trace.hs:7

Off the top of my head, you'll need to add a demangler as well.

> Wile we're at it, here's another issue we are struggling with:
>   #1  0x0000000000694330 in ?? () at rts/Updates.cmm:57
> What happens here is that 694330 gets derived correctly as the address
> to return to, but GDB actually seems to attempt to look up 69432f (= the
> address right in front) for display name and line number information.
> That might make sense for most compiled languages, but for GHC code, the
> space in front of return code pointers is an info table (= data). Hence
> GDB gets moderately confused when it can't find any information on it.
> So far we essentially hack around this by applying a suitable "offset"
> to line data as well as unwind information. That's why we have a source
> code pointer, and the stack trace doesn't simply stop at that point. But
> that's a rather crude solution, so any ideas would be appreciated.

I'm not really sure in this case. The model seems odd - are you
returning outside of the function's code / block range, or do you
have data in the middle of your function code? Perhaps a language
hook to provide flexibility in the offset...


More information about the Gdb mailing list