Making GDB recognize the Haskell DWARF source language ID

Making GDB recognize the Haskell DWARF source language ID

[Johan Tibell]

Hi,

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?

Cheers,
Johan

Re: Making GDB recognize the Haskell DWARF source language ID

[Joel Brobecker]

> 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.

-- 
Joel

Re: Making GDB recognize the Haskell DWARF source language ID

[Peter Wortmann]

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

Re: Making GDB recognize the Haskell DWARF source language ID

[Joel Brobecker]

> 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

Re: Making GDB recognize the Haskell DWARF source language ID

[Johan Tibell]

On Wed, Mar 5, 2014 at 4:16 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> 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...

Peter, do you have an assembly example for a single function that
includes both the function body and the data section that precedes it?

-- Johan

Re: Making GDB recognize the Haskell DWARF source language ID

[Peter Wortmann]

On Wed, 2014-03-05 at 15:16 +0000, Joel Brobecker wrote:
> >   #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...

Data in the middle of function code is about right - the idea is that
the return pointer doubles as frame layout description for garbage
collection. Here's roughly what our assembly looks like:

    .text
        .align 8
        .quad   1
        .loc 1 49 1 /* hack so GDB still shows line info */
        .quad   35
    stg_marked_upd_frame_info:
        .loc 1 49 1
        movq 8(%rbp),%rax
        movq 8(%rax),%rcx
        testq $7,%rcx

Note the ".quad"s that make up the info table for the function.

If I read the GDB code correctly, one of the sources of the problem is
that the get_frame_address_in_block function applies a "-1" offset for
"NORMAL_FRAME". The comment seems to suggest that this is to work
correctly with non-returning frames where the return pointer might be
invalid. However for Haskell, code return locations are pushed
explicitly, and decreasing it is guaranteed to land in no-man's-land.

Greetings,
  Peter Wortmann