unknown relocation: R_ARM_PLT32

[sieberst]

When I try to link my cross compiled ARM binary with mold 1.8.0, I get a lot of these errors from the libudev.a:

mold: error: ../Common/devices/udev/lib/arm/libudev.a(libudev.o):(.text): unknown relocation: R_ARM_PLT32

[rui314]

R_ARM_PLT32 is marked as https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#56111deprecated-relocations. We can still support it, but I want to know how it is being used. Can you upload your libudev.o?

[sieberst]

Sure, here is the libudev.a in a zip file:
libudev.zip

[sieberst]

Thanks for the quick update. I compiled mold from the current master in the docker container and tried it, unfortunately I now get a crash:
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped

[rui314]

What docker container did you use? I'm asking because I want to run the same command as you run in the same container to reproduce the issue.

[rui314]

Also please try again with the above commit.

[sieberst]

I used the docker container to build mold itself (i.e. running "./dist.sh").

I created a new binary from your current master, which seems to fix the crash but now gives the following error:

mold: fatal: ../Common/devices/udev/lib/arm/libudev.a(libudev-device.o):(.text): R_ARM_CALL refers neither BL nor BLX

[rui314]

How about this?

[sieberst]

With that the link finishes without errors. I still need to check whether the binary actually works...

[sieberst]

I have to correct myself, one of my binaries now can be linked, but another still fails with

collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped

The working binary is 18MB while the failing one is 35MB (when linked with gnu ld), maybe the error is caused by the size?

[rui314]

Can you get a stance of the crashed program?

[sieberst]

What do you mean by "stance"?

The weird thing is that the crash isn't deterministic. If I just run the same arm-none-linux-gnueabi-g++ link command several times, it often crashes but sometimes it links without a problem.

[rui314]

Sorry, it was a typo (I input it from my iPhone). I meant "stack trace".

[sieberst]

I tried to run the link command in gdb to get a stacktrace, but the trace isn't really helping (if you have another way to get a proper trace, let me know):

[Attaching after process 34526 vfork to child process 34531]
[New inferior 2 (process 34531)]
[Detaching vfork parent process 34526 after child exec]
[Inferior 1 (process 34526) detached]
process 34531 is executing new program: /data/conan/.conan/data/sdk_arm_dvf101/c32552a7adc5ff85dafafef45f0f91c8cd8ddf06/snom/stable/package/cb054d0b3e1ca595dc66bc2339d40f1f8f04ab31/sdk-buildroot/libexec/gcc/arm-none-linux-gnueabi/9.3.0/collect2
[Attaching after process 34531 vfork to child process 34532]
[New inferior 3 (process 34532)]
[Detaching vfork parent process 34531 after child exec]
[Inferior 2 (process 34531) detached]
process 34532 is executing new program: /data/steffen/mold-1.8.0-x86_64-linux/bin/mold
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Attaching after Thread 0x7ffff7fd2800 (LWP 34532) fork to child process 34533]
[New inferior 4 (process 34533)]
[Detaching after fork from parent process 34532]
[Inferior 3 (process 34532) detached]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6be3700 (LWP 34534)]
[New Thread 0x7ffff67e2700 (LWP 34535)]
[New Thread 0x7ffff63e1700 (LWP 34536)]
[New Thread 0x7ffff5fe0700 (LWP 34537)]
[New Thread 0x7ffff5bdf700 (LWP 34538)]
[New Thread 0x7ffff57de700 (LWP 34539)]
[New Thread 0x7ffff53dd700 (LWP 34540)]
[New Thread 0x7ffff4bdb700 (LWP 34542)]
[New Thread 0x7ffff47da700 (LWP 34543)]
[New Thread 0x7ffff43d9700 (LWP 34544)]
[New Thread 0x7ffff3fd8700 (LWP 34545)]
[New Thread 0x7ffff4fdc700 (LWP 34541)]
[New Thread 0x7ffff3bd7700 (LWP 34546)]
[New Thread 0x7ffff37d6700 (LWP 34548)]
[New Thread 0x7ffff33d5700 (LWP 34549)]
[New Thread 0x7ffff2bd3700 (LWP 34550)]
[New Thread 0x7ffff1fd0700 (LWP 34552)]
[New Thread 0x7ffff23d1700 (LWP 34553)]
[New Thread 0x7ffff27d2700 (LWP 34551)]
[New Thread 0x7ffff2fd4700 (LWP 34547)]
[New Thread 0x7ffff1b43700 (LWP 34554)]
[New Thread 0x7ffff1742700 (LWP 34555)]
[New Thread 0x7ffff1341700 (LWP 34556)]

Thread 4.6 "ld" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5bdf700 (LWP 34538)]
0x00005555565d2a45 in ?? ()
(gdb) bt
#0 0x00005555565d2a45 in ?? ()
#1 0x000002951c040080 in ?? ()
#2 0x00007fffe920bb16 in ?? ()
#3 0xfffffffffffffff8 in ?? ()
#4 0x00000000015f30cc in ?? ()
#5 0x00007fff00000120 in ?? ()
#6 0x0000000000000000 in ?? ()

[sieberst]

I made another test with a debug build of mold, maybe that is more helping, as there seems to be an assert triggering:

[Attaching after process 2284 vfork to child process 2289]
[New inferior 2 (process 2289)]
[Detaching vfork parent process 2284 after child exec]
[Inferior 1 (process 2284) detached]
process 2289 is executing new program: /data/conan/.conan/data/sdk_arm_dvf101/c32552a7adc5ff85dafafef45f0f91c8cd8ddf06/snom/stable/package/cb054d0b3e1ca595dc66bc2339d40f1f8f04ab31/sdk-buildroot/libexec/gcc/arm-none-linux-gnueabi/9.3.0/collect2
[Attaching after process 2289 vfork to child process 2290]
[New inferior 3 (process 2290)]
[Detaching vfork parent process 2289 after child exec]
[Inferior 2 (process 2289) detached]
process 2290 is executing new program: /data/steffen/mold-1.8.0-x86_64-linux/bin/mold
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Attaching after Thread 0x7ffff7fd2800 (LWP 2290) fork to child process 2293]
[New inferior 4 (process 2293)]
[Detaching after fork from parent process 2290]
[Inferior 3 (process 2290) detached]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6be3700 (LWP 2298)]
[New Thread 0x7ffff67e2700 (LWP 2299)]
[New Thread 0x7ffff63e1700 (LWP 2300)]
[New Thread 0x7ffff5fe0700 (LWP 2301)]
[New Thread 0x7ffff5bdf700 (LWP 2302)]
[New Thread 0x7ffff57de700 (LWP 2303)]
[New Thread 0x7ffff53dd700 (LWP 2304)]
[New Thread 0x7ffff4fdc700 (LWP 2306)]
[New Thread 0x7ffff4bdb700 (LWP 2307)]
[New Thread 0x7ffff43d9700 (LWP 2308)]
[New Thread 0x7ffff3fd8700 (LWP 2309)]
[New Thread 0x7ffff3bd7700 (LWP 2310)]
[New Thread 0x7ffff47da700 (LWP 2305)]
[New Thread 0x7ffff37d6700 (LWP 2311)]
[New Thread 0x7ffff33d5700 (LWP 2314)]
[New Thread 0x7ffff2bd3700 (LWP 2316)]
[New Thread 0x7ffff27d2700 (LWP 2317)]
[New Thread 0x7ffff1fd0700 (LWP 2318)]
[New Thread 0x7ffff23d1700 (LWP 2319)]
[New Thread 0x7ffff2fd4700 (LWP 2315)]
[New Thread 0x7ffff13cd700 (LWP 2321)]
[New Thread 0x7ffff17ce700 (LWP 2320)]
[New Thread 0x7ffff1bcf700 (LWP 2322)]

Thread 4.16 "ld" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff33d5700 (LWP 2314)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff6c24921 in __GI_abort () at abort.c:79
#2 0x00007ffff6c1448a in __assert_fail_base (fmt=0x7ffff6d9b750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555557636849 "ref.thunk_idx != -1",
file=file@entry=0x555557636786 "/mold/elf/mold.h", line=line@entry=2325,
function=function@entry=0x5555576367b8 "mold::u64 mold::elf::InputSection::get_thunk_addr(mold::i64) [with E = mold::elf::ARM32; mold::u64 = long unsigned int; mold::i64 = long int]") at assert.c:92
#3 0x00007ffff6c14502 in __GI___assert_fail (assertion=0x555557636849 "ref.thunk_idx != -1", file=0x555557636786 "/mold/elf/mold.h", line=2325,
function=0x5555576367b8 "mold::u64 mold::elf::InputSection::get_thunk_addr(mold::i64) [with E = mold::elf::ARM32; mold::u64 = long unsigned int; mold::i64 = long int]") at assert.c:101
#4 0x0000555555f13fab in ?? ()
#5 0x000000000000000e in ?? ()
#6 0x000002001c804180 in ?? ()
#7 0x0000000000000018 in ?? ()
#8 0xffffffffffffffff in ?? ()
#9 0x00007ffff33d46b0 in ?? ()
#10 0x000055555701c80d in ?? ()
#11 0x015ff614fffef860 in ?? ()
#12 0x00007ffff33d47d0 in ?? ()
#13 0x00007ffff33d49b0 in ?? ()
#14 0x000055555701d097 in ?? ()
#15 0x0000000000000000 in ?? ()

[sieberst]

When I link with the debug mold without gdb I get this output:

ld: /mold/elf/mold.h:2325: mold::u64 mold::elf::InputSection<E>::get_thunk_addr(mold::i64) [with E = mold::elf::ARM32; mold::u64 = long unsigned int; mold::i64 = long int]: Assertion `ref.thunk_idx != -1' failed.

[sieberst]

The initial problem seems to be fixed, but the segfault/assert still happens with the latest release. I created a new ticket for that issue so this one can be closed: #974