[Bug c/103908] New: gcc 7.5.0 (and earlier) miscompile asm goto in O1 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908 Bug ID: 103908 Summary: gcc 7.5.0 (and earlier) miscompile asm goto in O1 on x86-64 Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mathieu.desnoyers at efficios dot com Target Milestone: --- Created attachment 52122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52122=edit Reproducer for asm goto miscompilation in O1 (x86-64) gcc-7.5.0 and prior gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix How to reproduce: % gcc-7 -O1 -c -o hoisting.o hoisting.i % objdump -S hoisting.o hoisting.o: file format elf64-x86-64 Disassembly of section .text: : 0: c7 05 00 00 00 00 01movl $0x1,0x0(%rip)# a 7: 00 00 00 a: c3 retq Expected behavior: % gcc-8 -O1 -c -o hoisting.o hoisting.i % objdump -S hoisting.o hoisting.o: file format elf64-x86-64 Disassembly of section .text: : 0: 83 3d 00 00 00 00 00cmpl $0x0,0x0(%rip)# 7 7: 74 10 je 19 9: e8 00 00 00 00 callq e e: c7 05 00 00 00 00 01movl $0x1,0x0(%rip)# 18 15: 00 00 00 18: c3 retq 19: e8 00 00 00 00 callq 1e 1e: eb ee jmpe This issue appears to be fixed in gcc 8.1.0, but I did not find any bugzilla entry documenting this.
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589 --- Comment #18 from Mathieu Desnoyers --- Created attachment 51302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51302=edit Interceptor library working-around glibc's intl issues for malloc interceptors
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589 --- Comment #16 from Mathieu Desnoyers --- (In reply to Andrew Pinski from comment #15) > Maybe it is best if you file a glibc bug too. There was already a glibc bug reporting this. I've done the required changes to reopen it.
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589 --- Comment #14 from Mathieu Desnoyers --- I've proposed a RFC patch on the libc-alpha mailing list which fixes the issue: https://sourceware.org/pipermail/libc-alpha/2021-August/130129.html It does have a few downsides: it turns all i18n rwlocks into nestable mutexes, which may be slower when there are many concurrent readers. I've also changed all i18n locks to a nestable scheme, so maybe we can be more specific.
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589
Mathieu Desnoyers changed:
What|Removed |Added
CC||mathieu.desnoyers@efficios.
||com
--- Comment #13 from Mathieu Desnoyers
---
So I reproduced this hang with pgrep on my Ubuntu 18.04.1 LTS.
LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/{8,9,10,11}/libasan.so pgrep something
[ hang ]
but
LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/7/libasan.so pgrep something [ does
not hang ]
So I focus my investigation on gcc 8's libasan which is the first to introduce
this issue.
The version of glibc on this x86-64 machine is 2.27-3ubuntu1.4.
I added breakpoints on all rwlock read lock, write lock, and unlock operations
(__GI___pthread_rwlock_rdlock, __GI___pthread_rwlock_wrlock,
__GI___pthread_rwlock_unlock). Looking at what happens to the _nl_state_lock
which protects glibc's i18n handling data structures is quite enlightening.
This lock is _not_ a recursive lock. AFAIU what happens here is that:
1. intl/bindtextdom.c:set_binding_values() locks the _nl_state_lock write lock.
2. it calls malloc, but this symbol is overridden by libasan.
3. asan's malloc handler ReplaceSystemMalloc looks up "__libc_malloc_dispatch"
and if that fails it looks up "__libc_malloc_default_dispatch".
4. The dlsym lookup failure calls __dlerror, which performs a i18n lookup, thus
taking the _nl_state_lock read lock. This should not happen, as it is not a
nestable lock.
5. The _nl_state_lock is unlocked once after the i18n lookup is done.
6. The _nl_state lock is unlocked again in set_binding_values(), which corrupts
the lock state because it is not a nestable lock.
7. The next unlucky caller trying to take the lock hangs forever on futex.
Based on an IRC discussion with Carlos O'Donell, it appears to be a defect in
glibc that a malloc interposer fails during i18n translation. There was a
discussion back in 2014
(https://sourceware.org/legacy-ml/libc-alpha/2014-12/msg00954.html) regarding
reentrancy of dlopen and other libdl interfaces.
[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 --- Comment #11 from Mathieu Desnoyers --- The proposed fix "gcc9-pr90193.patch" applied on top of gcc-8.3.0 fixes the issue for both x86-64 and for x86-32 (-m32) from a 64-bit x86 gcc.
[Bug inline-asm/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193
--- Comment #2 from Mathieu Desnoyers
---
By the way, it can also be reproduced by replacing the "jmp" instruction within
the inline asm by a ".long":
# 1 "test-asm-goto-data.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "test-asm-goto-data.c"
__thread int var;
static int fct(void)
{
asm goto ( ".long %l[testlabel]\n\t"
: : [var] "m" (var) : : testlabel);
return 0;
testlabel:
return 1;
}
int main()
{
return fct();
}
[Bug inline-asm/90193] New: asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193
Bug ID: 90193
Summary: asm goto with TLS "m" input operand generates
incorrect assembler in O1 and O2
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: mathieu.desnoyers at efficios dot com
Target Milestone: ---
This issue can be reproduced with:
gcc version 8.3.0 (GCC)
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/efficios/local
Command line reproducing the bug:
/home/efficios/local/bin/gcc -O1 -o test-asm-goto test-asm-goto.c
(same with -O2)
Compiler output:
/tmp/ccsWO2Fm.o: In function `main':
test-asm-goto.c:(.text+0x1): undefined reference to `.L2'
collect2: error: ld returned 1 exit status
Preprocessed file reproducing the bug:
# 1 "test-asm-goto.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "test-asm-goto.c"
__thread int var;
static int fct(void)
{
asm goto ( "jmp %l[testlabel]\n\t"
: : [var] "m" (var) : : testlabel);
return 0;
testlabel:
return 1;
}
int main()
{
return fct();
}
It works fine with gcc 7.3.0 with and without optimizations, and it works fine
with gcc 8.3.0 without optimizations. It also affects compilation with -m32
(32-bit x86).
