Differences in symbol tables between old ld and mold

[arbernat]

I'm working on replacing our default linker with mold, and I ran into an interesting difference in behavior.

I'm building a shared library with the standard combination of function bodies and PLT stubs. With ld, for a function foo, I get two symbols in the static symbol table - "foo" and "foo.localalias" (actually, it's c++, so "foo" is mangled - but it works for the example). Both of these point to the function body, and the PLT stub doesn't have a symbol associated with it. In the dynamic symbol table there is one symbol, "foo", that also points to the function body.

With mold (version 1.0.1), I still have two symbols, but the static "foo" symbol points to the PLT stub instead of the function body. "foo.localalias" does point to the body, as does the dynamic symbol for "foo".

As a result of this, utilities like objdump are harder to use, since the first thing you find is the PLT stub.

With that said, two questions:

1. Is this behavior purposeful?
2. Is there a compatibility mode that generates symbols in the old manner?

Thank you!
Drew

Here's a code example.

Using the default system linker, with a function called "ps_atom_get":

root@aeb1ff035ed3:/build/src# nm libdefs-default.so | grep ps_atom_get
00000000000c1bf0 T _Z11ps_atom_getPKc
00000000000c1bf0 t _Z11ps_atom_getPKc.localalias

root@aeb1ff035ed3:/build/src# nm -D libdefs-default.so | grep ps_atom_get
00000000000c1bf0 T _Z11ps_atom_getPKc

00000000000c1bf0 <_Z11ps_atom_getPKc>:
   c1bf0:       f3 0f 1e fa             endbr64
   c1bf4:       41 56                   push   %r14
   c1bf6:       41 55                   push   %r13
   c1bf8:       41 54                   push   %r12
   c1bfa:       55                      push   %rbp

And using mold:

root@aeb1ff035ed3:/build/src/bld_linux/purity# nm lib/libdefsD.so  | grep ps_atom_get
00000000000c7080 T _Z11ps_atom_getPKc
00000000000c96d0 t _Z11ps_atom_getPKc.localalias

root@aeb1ff035ed3:/build/src# nm -D libdefs-mold.so | grep ps_atom_get
00000000000c96d0 T _Z11ps_atom_getPKc

00000000000c7080 <_Z11ps_atom_getPKc@plt>:
   c7080:       ff 25 ca 1f 04 00       jmpq   *0x41fca(%rip)        # 109050 <_Z11ps_atom_getPKc@@Base+0x3f980>
   c7086:       68 07 00 00 00          pushq  $0x7
   c708b:       e9 70 ff ff ff          jmpq   c7000 <driver_rev+0x24d8>

00000000000c96d0 <_Z11ps_atom_getPKc.localalias>:
   c96d0:       f3 0f 1e fa             endbr64
   c96d4:       41 56                   push   %r14
   c96d6:       41 55                   push   %r13
   c96d8:       41 54                   push   %r12
   c96da:       55                      push   %rbp

In case it helps, the mold linker is invoked as follows:

gcc-9 -Wl,--as-needed -Wl,--gdb-index -Wl,--compress-debug-sections=zlib -ggdb -m64 -march=corei7 -mtune=corei7-avx -mpku -Wall -Wtype-limits -Wswitch-enum -ftls-model=initial-exec -fPIE -pie -fPIC -shared -Wl,--build-id -B/usr/libexec/mold -Wl,-hlibdefsD.so -o /build/src/bld_linux/purity/lib/libdefsD.so <.o files>

[rui314]

mold 1.0.1 is very old. I have fixed tons of subtle compatibility issues since releasing 1.0.1. Can you upgrade to the latest version of mold and try again?

[arbernat]

1.2.1 works perfectly! We needed a couple of extra patches (2e47fe5 and 73a9b6e, --gdb-index stuff) to not crash in execution, but the symbol identification looks great.

I'll keep an eye open for an official 1.2.2 release so I can hand it to our build team, and in the meantime use our patched build myself :) Thank you!

[rui314]

Glad to hear that 1.2.1 worked for you. Since many bug fixes have been accumulated, I’ll probably release the next stable release this month.