ld seems to disregard section relative specifiers on symbols

Mark Harmstone mark@harmstone.com
Mon Sep 9 20:35:32 GMT 2024


On 09/09/2024 10:08, Jan Beulich wrote:
> On 05.09.2024 14:58, Julian Waters wrote:
>> clang's lld correctly patches the code to use section relative offsets in
>> this instance, because the @secrel specifier was requested, while ld
>> incorrectly patches the address to be the absolute value. This appears to
>> be strictly an ld bug, because compiling with gcc or assembling with as and
>> then linking with clang lld yields the correct section relative offset of
>> 8. This bug is a significant showstopper in the recent attempts to add TLS
>> support on Windows to gcc, so I'm invested in having it fixed. Is there any
>> hint as to why ld is ignoring the @secrel modifier?

For anybody making the same mistake as I did when trying this out, it looks like
Wine doesn't do ASLR, so you only get the incorrect relocation on Windows.

> Mark, with this change one of the PDB tests yields "FAIL: Incorrect section
> contribution substream". In the absence of any documentation in ld-pe/pdb.exp,
> how is one to understand whether in fact something broke, or whether a test's
> expectations simply need updating (and then in which way)? I surely won't
> want to go from just what the new output is, but understand why it changed
> and why/whether it previously was correct in the first place. When putting
> together that test, it seems quite likely that you would have noticed that
> there's a bogus base relocation in the .exe, which apparently is related to
> what's being put in the .pdb.

Yes, I know it's opaque, the documentation is nearly non-existent. The best way
is to run Microsoft's cvdump.exe against the PDB or object files, which
outputs the CodeView data in text format.

So for pdb2.pdb we get:

(before)
*** SECTION CONTRIBUTIONS

   Imod  Address        Size      Characteristics
   0001  0001:00000000  00000010  60000020
   0002  0001:00000010  00000010  60000020
   0001  0002:00000000  0000003D  40000040
   0003  0004:00000000  0000000C  42000040

(after)
*** SECTION CONTRIBUTIONS

   Imod  Address        Size      Characteristics
   0001  0001:00000000  00000010  60000020
   0002  0001:00000010  00000010  60000020
   0001  0002:00000000  0000003D  40000040

i.e. like you say, it removes the .reloc section. Input module 3 is the dummy
"dll stuff" linker object.

 > When putting
 > together that test, it seems quite likely that you would have noticed that
 > there's a bogus base relocation in the .exe, which apparently is related to
 > what's being put in the .pdb.

I noticed but thought it was legit. The .secrel32 in pdb2a.s isn't PDB output,
but only there so that bar doesn't get GC'd. I remember struggling with finding
a way to do this for both 32- and 64-bit that gave identical outputs.

Mark


More information about the Binutils mailing list