Re: Making GDB recognize the Haskell DWARF source language ID

[Joel Brobecker <brobecker@adacore.com>]

> https://ghc.haskell.org/trac/ghc/ticket/3693#comment:44
> 
> 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...

-- 
Joel