Re: Making GDB recognize the Haskell DWARF source language ID

[Peter Wortmann <scpmw@leeds.ac.uk>]

Joel Brobecker wrote:
> > We recently added DWARF output support to GHC, the main Haskell
> > compiler. However, GDB doesn't seem to respect the function names we
> > output as DWARF debug info and instead falls back to the symbol names.
> > My understanding is that this is due to the DWARF source language ID
> > we emit isn't recognized by GDB. Is this correct and, if so, how do we
> > remedy the situation?
> 
> I am wondering if your issue might go deeper than just recognizing
> the language, but instead actually implement haskell support within
> GDB. Hard to tell without more details of what's going on. Perhaps
> a copy/past of a debugger sessions, annotated with what you would
> have expected would help give you more details.

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

This is the issue Johan was talking about: We get the scrambled symbol
table name, even though we have a complete .debug_info record:

 <1><37f>: Abbrev Number: 2 (DW_TAG_subprogram)
    <380>   DW_AT_name        : fib_err 
    <388>   DW_AT_MIPS_linkage_name: Main_zdwfibzuerr_info      
    <39e>   DW_AT_external    : 255     
    <39f>   DW_AT_low_pc      : 0x4041c8        
    <3a7>   DW_AT_high_pc     : 0x40422e        

Which we would expect to result in the more useful "fib_err" getting
shown. The actual story here seems to be that the linkage name
overwrites the proper name, which from reading the source seems to be a
language-specific decision?

(Note: Yes, the addresses don't match, different compilation, sorry)


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.

Greetings,
  Peter Wortmann