lld mingw undefined weak symbol, --wrap, import library, and relocation results in garbage pointer

[jeremyd2019]

There are several moving parts here that seem to be necessary to reproduce this, so bear with me. This is an attempt to reduce something from a more complicated situation inside Cygwin startup code.

testreal.c

void foo (void)
{ }

testweak.c

void __wrap_foo (void)
{ }

extern __attribute__ ((weak)) void foo (void) __asm__ ("__real_foo");

void (*bar)(void) = &foo;

int main (void)
{
        return !!bar;
}

clang -shared -o testreal.dll -Wl,-out-implib,testreal.a testreal.c -Wl,--wrap,foo
clang -o testweak testweak.c testreal.a -fuse-ld=lld -Wl,--wrap,foo

With lld running testweak returns 1, with bfd it returns 0. If you inspect the pointer in a debugger, it is garbage with lld.

Thread 1 hit Breakpoint 1, 0x00007ff7a3da146f in main ()
(gdb) p (void *)bar
$1 = (void *) 0x7ff663da0000

If you remove the dynamicbase flag (so the testweak.exe does not need to be relocated) it returns 0 with lld

clang -o testweak testweak.c testreal.a -Wl,--wrap,foo -fuse-ld=lld -Wl,--disable-dynamicbase

Tested with x86_64-w64-mingw32 and x86_64-pc-cygwin targets

@mstorsjo @kikairoya @tyan0

[llvmbot]

@llvm/issue-subscribers-lld-coff

Author: None (jeremyd2019)

There are several moving parts here that seem to be necessary to reproduce this, so bear with me. This is an attempt to reduce something from a more complicated situation inside Cygwin startup code.

testreal.c

void foo (void)
{ }

testweak.c

void __wrap_foo (void)
{ }

extern __attribute__ ((weak)) void foo (void) __asm__ ("__real_foo");

void (*bar)(void) = &foo;

int main (void)
{
        return !!bar;
}

clang -shared -o testreal.dll -Wl,-out-implib,testreal.a testreal.c -Wl,--wrap,foo
clang -o testweak testweak.c testreal.a -fuse-ld=lld -Wl,--wrap,foo

With lld running testweak returns 1, with bfd it returns 0. If you inspect the pointer in a debugger, it is garbage with lld.

Thread 1 hit Breakpoint 1, 0x00007ff7a3da146f in main ()
(gdb) p (void *)bar
$1 = (void *) 0x7ff663da0000

If you remove the dynamicbase flag (so the testweak.exe does not need to be relocated) it returns 0 with lld

clang -o testweak testweak.c testreal.a -Wl,--wrap,foo -fuse-ld=lld -Wl,--disable-dynamicbase

Tested with x86_64-w64-mingw32 and x86_64-pc-cygwin targets

@mstorsjo @kikairoya @tyan0

[jeremyd2019]

If you want to link testreal.dll with lld you'll need __wrap_foo function in testreal.c as well (the end result in testweak.exe is the same). This is kind of an odd thing, too (that lld requires __wrap_foo to be defined while bfd does not), but I don't know if it's a bug or not.

[jeremyd2019]

Another weird thing is that if you reference foo in testweak.exe (from another compilation unit), bfd will keep bar as NULL but lld will fill it in with the address of the foo jump stub. It'd be nice if this worked like bfd also, for Cygwin's sake. though it's not entirely clear to me why bfd's behavior is how it is.

[kikairoya]

Thank you for detailed explanation!

There is another odd thing -- compiling testweak.c to another DLL (and call it from a stub EXE) makes bar as NULL even if dynamicbase is enabled or image-base is overlapped with the stub EXE. Am I misunderstanding about base relocation?
Linking to testreal.a was missing. There is no difference between EXE and DLL for this problem.

[kikairoya]

In my understand, this problem is caused by the following combination of issues:

1. --wrap foo has no effect if foo is neither defined nor referenced, even if __wrap_foo or __real_foo are present.
2. The weak linkage of foo (__real_foo) no longer applies after it is redirected to __wrap_foo (foo).
3. If __wrap_foo is introduced solely via --wrap foo (i.e., not explicitly referenced or defined in any input file), it is treated as a strong undefined symbol.

After treat them, linking with BFD-made import library seems fine. However, LLD-made import library still makes garbage and linking to DLL directly can't import redirected weak symbols.

WIP branch: main...kikairoya:llvm-project:lld-weak-wrap
test unit: https://gist.github.com/kikairoya/229ec2ff83637f6742e6c0da07749bb3

[jeremyd2019]

After treat them, linking with BFD-made import library seems fine. However, LLD-made import library still makes garbage and linking to DLL directly can't import redirected weak symbols.

Potentially because the "thin" import library format doesn't actually contain the jump stub, and it ends up being synthesized by LLD. Maybe somewhere around SymbolTable::addImportThunk or Writer::appendImportThunks ?

[kikairoya]

After treat them, linking with BFD-made import library seems fine. However, LLD-made import library still makes garbage and linking to DLL directly can't import redirected weak symbols.

Potentially because the "thin" import library format doesn't actually contain the jump stub, and it ends up being synthesized by LLD.

I found the difference - LLD and BFD-ld both emit a thunk with an unmangled symbol into the import library, except when the export is produced by the effect of --export-all-symbols in BFD-ld, in which case the unmangled symbol is missing. In other words, BFD-ld switches the format of the import library depending on whether -export:xxxx is present in the .drectve section.

[jeremyd2019]

what? could you show a diff of nm output or something to demonstrate that?

[kikairoya]

with this (run on msys2 UCRT64):

#!/bin/bash

cat > exports.s <<EOF
  .text
  .global explicit
explicit:
  ret

  .global implicit
implicit:
  ret

  .section .drectve
  .ascii " -export:explicit "

EOF

gcc -c exports.s -o exports.o
ld.bfd -m i386pep --dll exports.o -o bfd.dll --out-implib bfd.dll.a --entry= --export-all-symbols
ld.lld -m i386pep --dll exports.o -o lld.dll --out-implib lld.dll.a --entry= --export-all-symbols

dump() {
  echo $1
  objdump $1 --disassemble=$(awk '{print $3;}' <<<$3) | grep -v "file format"
}

echo === BFD ===============================================
nm bfd.dll.a | grep plicit | mapfile -t -C "dump bfd.dll.a" -c 1
echo === LLD ===============================================
nm lld.dll.a | grep plicit | mapfile -t -C "dump lld.dll.a" -c 1

shows (wish squashing blank lines)

=== BFD ===============================================
0000000000000000 I __imp_implicit
In archive bfd.dll.a:

Disassembly of section .text:
0000000000000000 I __nm_implicit
In archive bfd.dll.a:

Disassembly of section .text:
0000000000000000 I __imp_explicit
In archive bfd.dll.a:

Disassembly of section .text:
0000000000000000 T explicit
In archive bfd.dll.a:

Disassembly of section .text:

0000000000000000 <explicit>:
   0:   ff 25 00 00 00 00       jmp    *0x0(%rip)        # 6 <explicit+0x6>
   6:   90                      nop
   7:   90                      nop
=== LLD ===============================================
0000000000000000 I __imp_explicit
In archive lld.dll.a:

Disassembly of section .text:

Disassembly of section .text:
0000000000000000 T explicit
In archive lld.dll.a:

Disassembly of section .text:

0000000000000000 <explicit>:
   0:   ff 25 00 00 00 00       jmp    *0x0(%rip)        # 6 <explicit+0x6>
   6:   90                      nop
   7:   90                      nop

Disassembly of section .text:
0000000000000000 I __imp_implicit
In archive lld.dll.a:

Disassembly of section .text:

Disassembly of section .text:
0000000000000000 T implicit
In archive lld.dll.a:

Disassembly of section .text:

Disassembly of section .text:

0000000000000000 <implicit>:
   0:   ff 25 00 00 00 00       jmp    *0x0(%rip)        # 6 <implicit+0x6>
   6:   90                      nop
   7:   90                      nop

(EDIT: fixed paste miss)

BFD's output has explicit but not implicit (__nm_implicit instead). LLD's one has both.

[kikairoya]

BFD has the option named --compat-implib but seems no effect on this.

[jeremyd2019]

The lack of the implicit is most likely due to the fact that your assembly is missing the magic that tells ld.bfd that the symbol is a function and not data. This is

.def    implicit;   .scl    2;      .type   32;     .endef

(explicit should have this too, maybe -export drective implies that?)