[llvm] r187656 - Bugfix for making the DWARF debug strings and labels to code emitted as secrel32 instead of long opcodes (only for coff). This makes them debuggable with GDB (with fix for 64bits msvc)

[David Blaikie]

On Fri, Aug 2, 2013 at 2:22 PM, Carlo Kok <ck at remobjects.com> wrote:
> Op 2-8-2013 22:18, David Blaikie schreef:
>
>> On Fri, Aug 2, 2013 at 11:57 AM, ck at remobjects.com <ck at remobjects.com>
>> wrote:
>>>
>>> I Did actually. After this patch it could load it in both gdb 32 and 64
>>> without error.
>>
>>
>> Great, thanks for checking.
>>
>> (though it is curious that a 32 bit special case is needed but not a
>> 64 - not that I know much/anything about this stuff. Perhaps there's a
>> GDB bug to file too? (if this is a workaround for a GDB bug, a FIXME
>> or note saying that would be useful too))
>>
>>
>
> it's actually needed for both 32 and 64 bits coff, but only if the value is
> emitted as a 4 byte address. Not for a 64bits one (which should use .quad).
> That was what I broke yesterday, one of the addresses that should be 64bits
> was emitted as 32bits. I used GDB (and objdump) as a base line because
> they're the closest thing I could find for dwarf validation for coff, and I
> don't think this is a bug (i can't trust llvm-dwarfdump as it doesn't
> support any of the coff relocations). From what I could find in the spec,
> some things are done as relative offsets (what hits for secrel32), some
> things are "address" types of ptrsize.

Do you know if this is a limitation of the format, or just of the
debugger's ability to read? I've hit bugs before where only the 32 or
64 bit case have been implemented because that's all that was needed.
If there is a sensible generic solution to 32 and 64 bit and it's just
GDB (or the linker) being silly & special casing, then it'd be nice to
document that we're working around a bug in another tool (& file a bug
for that tool).

If you can use a .quad address, I'd expect a .long address if it
needed to be 32 bits.

> I will be using this code (and
> presumably others too looking at the nr of times this has come up) so if I
> find more issues I'll be sure to do another patch and request for comments,
> which I think will be the most practical way to go about this, unless
> someone knows a fool proof dwarf validation tool that actually works with
> pe/coff for win32 and 64.
>
>
>
> --
> Carlo Kok
>