Bug 1351341
| Summary: | gcc -fsanitize=address fails to link objects that contain "longjmp" call | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Stahl <mstahl> |
| Component: | binutils | Assignee: | Nick Clifton <nickc> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | codonell, fweimer, jakub, nickc |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | binutils-2.26.1-1.fc24 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-05 04:56:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The longjmp function has been moved into the pthread library. (I do not know why). So if you add -lpthread to your command line, eveyrything should work: gcc -m32 -fsanitize=address foo.c -lpthread (In reply to Nick Clifton from comment #1) > The longjmp function has been moved into the pthread library. (I do not > know why). But there is a definition of longjmp in libc.so.6 with a default symbol version, so it should be picked up: $ eu-readelf -s /lib/libc.so.6 | grep longjmp 257: 00108ed0 85 FUNC GLOBAL DEFAULT 13 __longjmp_chk@@GLIBC_2.11 325: 0002d3e0 81 FUNC WEAK DEFAULT 13 _longjmp@@GLIBC_2.0 1053: 0002d3e0 81 FUNC WEAK DEFAULT 13 longjmp@@GLIBC_2.0 … But anyway, the intent is that the non-version interpositioning definition in libasan is used: $ eu-readelf -s /lib/libasan.so.3 | grep longjmp 524: 00028ea0 46 FUNC WEAK DEFAULT 12 _longjmp 580: 00028e70 46 FUNC WEAK DEFAULT 12 longjmp … The ld command line looks like this: ["/usr/bin/ld", "-plugin", "/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/liblto_plugin.so", "-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper", "-plugin-opt=-fresolution=/tmp/ccndqKIy.res", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "--build-id", "--no-add-needed", "--eh-frame-hdr", "--hash-style=gnu", "-m", "elf_i386", "-dynamic-linker", "/lib/ld-linux.so.2", "/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../lib/crt1.o", "/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../lib/crti.o", "/usr/lib/gcc/x86_64-redhat-linux/6.1.1/32/crtbegin.o", "-L/usr/lib/gcc/x86_64-redhat-linux/6.1.1/32", "-L/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../lib", "-L/lib/../lib", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-redhat-linux/6.1.1", "-L/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../..", "/usr/lib/gcc/x86_64-redhat-linux/6.1.1/32/libasan_preinit.o", "-lasan", "/tmp/cc82m9kC.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_64-redhat-linux/6.1.1/32/crtend.o", "/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../lib/crtn.o"] Why isn't ld able to find a definition for the longjmp symbol? binutils-2.26.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-afcbebcc78 Good news, bad bews: Bad news - the problem is a linker bug. I think that it is probably because the longjmp symbol in libc.so.6 is weak, but I could not find a binutils PR to match against this. Good news - the bug is fixed in the 2.26.1 FSF binutils point release, and yesterday I upgraded the F24 binutils to use these new sources. So if you try out: binutils-2.26.1-1.fc24 The problem should go away. I have submitted a bohdi request to have this new rpm released as an update. (As an aside, I have not updated rawhide because the new FSF 2.27 release is due to come out soon). binutils-2.26.1-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-afcbebcc78 binutils-2.26.1-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: linking an executable where objects contain a call to "longjmp" fails when "-fsanitize=address" is used Version-Release number of selected component (if applicable): binutils-2.26-18.fc24.x86_64 glibc-2.23.1-8.fc24.x86_64 glibc-devel-2.23.1-8.fc24.i686 glibc-all-langpacks-2.23.1-8.fc24.x86_64 glibc-2.23.1-8.fc24.i686 glibc-headers-2.23.1-8.fc24.x86_64 glibc-common-2.23.1-8.fc24.x86_64 glibc-devel-2.23.1-8.fc24.x86_64 libgcc-6.1.1-3.fc24.x86_64 gcc-c++-6.1.1-3.fc24.x86_64 gcc-6.1.1-3.fc24.x86_64 libgcc-6.1.1-3.fc24.i686 libasan-static-6.1.1-3.fc24.i686 libasan-static-6.1.1-3.fc24.x86_64 libasan-6.1.1-3.fc24.i686 libasan-6.1.1-3.fc24.x86_64 How reproducible: always Steps to Reproduce: 1. cat > foo.c #include <setjmp.h> int main() { jmp_buf foo; longjmp(foo, 0); } 2. gcc -m32 -fsanitize=address foo.c Actual results: /usr/bin/ld: /usr/lib/libasan.so.3.0.0: undefined reference to symbol 'longjmp' /lib/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status the 64-bit build fails similarly, with a different symbol version: /usr/bin/ld: /usr/lib64/libasan.so.3.0.0: undefined reference to symbol 'longjmp.5' /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Expected results: executable is linked Additional info: this was found by building LibreOffice with "-m32 -fsanitize=address" with Executable_ucpp and Executable_oosplash this used to work on Fedora 23