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