[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)

Carlo Kok ck at remobjects.com
Fri Aug 2 14:22:40 PDT 2013


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. 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




More information about the llvm-commits mailing list