Re: Making GDB recognize the Haskell DWARF source language ID

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

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