Re: Making GDB recognize the Haskell DWARF source language ID

Johan Tibell <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CAK-tuPbjpp2cgugumxd=oUfHXsc_3PT2imY7X4tixJdrG9q+wg@mail.gmail.com>
On Wed, Mar 5, 2014 at 4:16 PM, Joel Brobecker <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.