This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Making GDB recognize the Haskell DWARF source language ID
- From: Peter Wortmann <scpmw at leeds dot ac dot uk>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Johan Tibell <johan dot tibell at gmail dot com>, gdb <gdb at sourceware dot org>
- Date: Wed, 05 Mar 2014 18:06:14 +0000
- Subject: Re: Making GDB recognize the Haskell DWARF source language ID
- Authentication-results: sourceware.org; auth=none
- References: <CAK-tuPb6LfiKYzqAjexraPPE0g4SqLN4XY55L=Ca6xGnTW+SuA at mail dot gmail dot com> <20140228163339 dot GC4860 at adacore dot com> <1393610228 dot 3893 dot 49 dot camel at cslin101 dot csunix dot comp dot leeds dot ac dot uk> <20140305151609 dot GP4860 at adacore dot com>
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