Re: Making GDB recognize the Haskell DWARF source language ID

[Johan Tibell <johan.tibell@gmail.com>]

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