Bug #13684
closedld aborts when input object has no file name
100%
Description
I was trying to set up afl++ from https://github.com/AFLplusplus/AFLplusplus and it does something a little bit unconventional that causes ld to abort:
@echo 'main() { __asm__("xorb %al, %al"); }' | $(CC) $(CFLAGS) -w -x c - -o .test1 || ( echo; echo "Oops, looks like your compiler can't generate x86 code."; echo; echo "Don't panic! You can use the LLVM or QEMU mode, but see docs/INSTALL first."; echo "(To ignore this error, set AFL_NO_X86=1 and try again.)"; echo; exit 1 )
However, this causes ld to blow up using relatively recent bits:
> ::status debugging core file of ld (64-bit) from beowulf file: /usr/bin/amd64/ld initial argv: /bin/ld -Y P,/usr/gcc/10/lib/amd64:/lib/amd64:/usr/lib/amd64 -R /usr/gcc/10/lib threading model: native threads status: process terminated by SIGABRT (Abort), pid=426966 uid=100 code=-1 libc panic message: Assertion failed: dynsym == (ldynsym + ldynsym_ndx), file /ws/rm/pcie/usr/src/cmd/sgs/libld/common/update.c, line 2010, function update_osym > $C fffffc7fffdf33f0 libc.so.1`_lwp_kill+0xa() fffffc7fffdf3420 libc.so.1`raise+0x1e(6) fffffc7fffdf3470 libc.so.1`abort+0x58() fffffc7fffdf36e0 0xfffffc7febb7c9a2() fffffc7fffdf3900 libld.so.4`update_osym+0x31af(fffffc7feaa00020) fffffc7fffdf3a00 libld.so.4`ld64_update_outfile+0x53b(fffffc7feaa00020) fffffc7fffdf3a80 libld.so.4`ld64_main+0x53f(25, fffffc7fffdf3b18, 3e) fffffc7fffdf3ac0 main+0xf2() fffffc7fffdf3af0 _start_crt+0x87() fffffc7fffdf3b00 _start+0x18() > rm@beowulf:~/afl/AFLplusplus$ pargs core core 'core' of 426966: /bin/ld -Y P,/usr/gcc/10/lib/amd64:/lib/amd64:/usr/lib/amd64 -R /usr/gcc/10/lib argv[0]: /bin/ld argv[1]: -Y argv[2]: P,/usr/gcc/10/lib/amd64 argv[3]: -R argv[4]: /usr/gcc/10/lib/amd64 argv[5]: -L argv[6]: /usr/gcc/10/lib/amd64 argv[7]: -Qy argv[8]: -o argv[9]: .test1 argv[10]: /usr/lib/amd64/crt1.o argv[11]: /opt/gcc-10/lib/gcc/x86_64-pc-solaris2.11/10.2.0/crtp.o argv[12]: /usr/lib/amd64/crti.o argv[13]: /usr/lib/amd64/values-Xa.o argv[14]: /usr/lib/amd64/values-xpg6.o argv[15]: /opt/gcc-10/lib/gcc/x86_64-pc-solaris2.11/10.2.0/crtbegin.o argv[16]: -L/opt/gcc-10/lib/gcc/x86_64-pc-solaris2.11/10.2.0 argv[17]: -L/opt/gcc-10/lib/gcc/x86_64-pc-solaris2.11/10.2.0/../../../amd64 argv[18]: -L/lib/amd64 argv[19]: -L/usr/lib/amd64 argv[20]: -L/opt/gcc-10/lib/gcc/x86_64-pc-solaris2.11/10.2.0/../../.. argv[21]: /var/tmp//ccYLG0dA.o argv[22]: -lgcc argv[23]: -z argv[24]: ignore argv[25]: -lgcc_s argv[26]: -z argv[27]: record argv[28]: -lc argv[29]: -lgcc argv[30]: -z argv[31]: ignore argv[32]: -lgcc_s argv[33]: -z argv[34]: record argv[35]: /opt/gcc-10/lib/gcc/x86_64-pc-solaris2.11/10.2.0/crtend.o argv[36]: /usr/lib/amd64/crtn.o
We should probably figure out what's causing ld to abort as it does not cause gld to abort.
Files
Updated by Rich Lowe about 1 year ago
I'm almost positive we must abort in that case, and what we instead need to know how is how/why we got here
Updated by Rich Lowe about 1 year ago
- Category changed from cifs - CIFS server and client to tools - gate/build tools
Updated by Rich Lowe about 1 year ago
It looks like you pasted the snippet from test1, but the core is from test2. Can you paste that as well?
Updated by Robert Mustacchi about 1 year ago
I updated this with the right instance, I think I had a second core and accidentally plowed over the first. This is trivially reproducible with the following:
echo 'main() { __asm__("xorb %al, %al"); }' | gcc -w -x c - -o .test1 Assertion failed: dynsym == (ldynsym + ldynsym_ndx), file /ws/rm/pcie/usr/src/cmd/sgs/libld/common/update.c, line 2010, function update_osym collect2: fatal error: ld terminated with signal 6 [Abort], core dumped compilation terminated.
Apologies, wasn't trying to suggest we should just remove the assert, just meant we should fix whatever's actually going on.
Updated by Robert Mustacchi about 1 year ago
I've attached a bugger-ld run of this.
Updated by Rich Lowe about 1 year ago
Updated by Rich Lowe about 1 year ago
- Status changed from New to In Progress
- Assignee set to Rich Lowe
Updated by Rich Lowe about 1 year ago
- Subject changed from ld aborts building afl++ to ld aborts when input object has no file name
Updated by Rich Lowe about 1 year ago
This is because the compiler is taking input from stdin, and so the file symbol it creates is nameless. We ignore nameless symbols for ldynsym when calculating its size, but unfortunately not when copying entries from the symtab to ldynsym.
Updated by Rich Lowe about 1 year ago
The logic in the above comment is backwards, but still descriptive.
When calculating sizes we ignore nameless symbols, but we do need to keep any file symbols to maintain the semantic in symbol tables that local symbols follow the file symbol of the file they were defined in.
Additionally, as Dan noted in the review that I didn't describe here. We should not be doing this check with sdp->sd_name in any case, because that will never be NULL for us it'll be a pointer to '\0'
Updated by Rich Lowe about 1 year ago
Testing with reproduction means Robert gave me. Robert tested
specifically for me, I wsdiff'd an illumos build with clean results
(except the SGS version changing)
Updated by Electric Monk about 1 year ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit f980a4bbce3d867e2bb5e61c180593f416d181a5
commit f980a4bbce3d867e2bb5e61c180593f416d181a5 Author: Richard Lowe <richlowe@richlowe.net> Date: 2021-04-05T19:04:36.000Z 13684 ld aborts when input object has no file name Reviewed by: Dan McDonald <danmcd@joyent.com> Reviewed by: Gordon Ross <Gordon.W.Ross@gmail.com> Approved by: Robert Mustacchi <rm@fingolfin.org>