Project

General

Profile

Actions

Bug #13684

closed

ld aborts when input object has no file name

Added by Robert Mustacchi about 1 month ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
tools - gate/build tools
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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

Actions #1

Updated by Rich Lowe about 1 month 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

Actions #2

Updated by Rich Lowe about 1 month ago

  • Category changed from cifs - CIFS server and client to tools - gate/build tools
Actions #3

Updated by Rich Lowe about 1 month ago

It looks like you pasted the snippet from test1, but the core is from test2. Can you paste that as well?

Actions #4

Updated by Robert Mustacchi about 1 month ago

  • Description updated (diff)
Actions #5

Updated by Robert Mustacchi about 1 month 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.

Actions #6

Updated by Robert Mustacchi about 1 month ago

I've attached a bugger-ld run of this.

Actions #7

Updated by Electric Monk about 1 month ago

  • Gerrit CR set to 1379
Actions #9

Updated by Rich Lowe about 1 month ago

  • Status changed from New to In Progress
  • Assignee set to Rich Lowe
Actions #10

Updated by Rich Lowe about 1 month ago

  • Subject changed from ld aborts building afl++ to ld aborts when input object has no file name
Actions #11

Updated by Rich Lowe about 1 month 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.

Actions #12

Updated by Rich Lowe about 1 month 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'

Actions #13

Updated by Rich Lowe about 1 month 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)

Actions #14

Updated by Electric Monk about 1 month 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>

Actions

Also available in: Atom PDF