https://sourceware.org/bugzilla/show_bug.cgi?id=28348
Bug ID: 28348
Summary: ld generates corrupted binaries with clang
-fsanitize=address -lc
Product: binutils
Version: 2.37
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: doko at debian dot org
Target Milestone: ---
Created attachment 13668
--> https://sourceware.org/bugzilla/attachment.cgi?id=13668&action=edit
files for linking
[forwarded from https://bugs.debian.org/994530]
"""
When clang is used with both -fsanitize=address and -lc, ld silently generates
binaries contains corrupted symbols as reported by readelf:
$ cat test_asan_lc.c
// Test asan with lc https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876973
//
// REQUIRES: clang
// RUN: %clang -fsanitize=address %s -o %t -lc
// RUN: %t
// XFAIL: i686, i386
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello world!\n");
return 0;
}
$ clang-11 -fsanitize=address test_asan_lc.c -o test_asan_lc -lc
$ readelf -a test_asan_lc | grep '<corrupt>'
634: 0000000000483090 9 FUNC WEAK DEFAULT 15 longjmp@@<corrupt>
1905: 0000000000483120 9 FUNC WEAK DEFAULT 15
siglongjmp@@<corrupt>
This doesn't happen when not using -lc
$ clang-11 -fsanitize=address test_asan_lc.c -o test_asan_lc
$ readelf -a test_asan_lc | grep '<corrupt>'
The issues happens at least on amd64 and arm64. Up to know ld.so has
been able to work despite these broken symbols. Following the move of
the pthread_gettattr_np symbols from libpthread.so to libc.so [1], this
is not longer the case on arm64, where ld.so fails when looking up the
longjmp symbol.
This causes the llvm-toolchain-11 [2] and llvm-toolchain-12 [3] to fail,
blocking the glibc 2.32 transition.
Please find attached the test_asan_lc.c source code, as well as a
reproducer calling ld directly with all the arm64 objects included.
"""
--
You are receiving this mail because:
You are on the CC list for the bug.
