[Bug gas/31115] [ARM] The minimalistic DWARF DIE for function has wrong address in Thumb mode
https://sourceware.org/bugzilla/show_bug.cgi?id=31115 --- Comment #7 from Sourceware Commits --- The master branch has been updated by Tom de Vries : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8a61ee551ce3059f602fee1e576af08c03f991bc commit 8a61ee551ce3059f602fee1e576af08c03f991bc Author: Tom de Vries Date: Wed Mar 20 09:57:49 2024 +0100 [gdb/symtab] Workaround PR gas/31115 On arm-linux, with gas 2.40, I run into: ... (gdb) x /i main+8^M 0x4e1 : vrhadd.u16 d14, d14, d31^M (gdb) FAIL: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try) ... This is a regression due to PR gas/31115, which makes gas produce a low_pc with the thumb bit set (0x4d8 & 0x1): ... <1><24>: Abbrev Number: 2 (DW_TAG_subprogram) <25> DW_AT_name: main <29> DW_AT_external: 1 <29> DW_AT_type: <0x2f> <2a> DW_AT_low_pc : 0x4d9 <2e> DW_AT_high_pc : 12 ... The regression was introduced in 2.39, and is also present in 2.40 and 2.41, and hasn't been fixed yet. Work around this in read_func_scope, by using gdbarch_addr_bits_remove on low_pc and high_pc. Tested on arm-linux and x86_64-linux. PR tdep/31453 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31453 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31115] [ARM] The minimalistic DWARF DIE for function has wrong address in Thumb mode
https://sourceware.org/bugzilla/show_bug.cgi?id=31115 H.J. Lu changed: What|Removed |Added CC||jbeulich at suse dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31457] strip: SEGV in copy_archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31457 --- Comment #2 from Driller SE --- I'm also confused by this problem. I couldn't reproduce the problem 100% at each execution before. Even though I haven't updated the binutils for testing, this problem cannot be reproduced in my current environment. I guess the triggering of this problem may require a specific external environment (e.g. special memory state, special disk state, etc.) I'll try to figure out what's going on (if possible). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30569] MIPS16 function stub assertion fail for mipsel_24kc_24kf
https://sourceware.org/bugzilla/show_bug.cgi?id=30569 Christian Marangi (Ansuel) changed: What|Removed |Added CC||ansuelsmth at gmail dot com --- Comment #1 from Christian Marangi (Ansuel) --- Created attachment 15422 --> https://sourceware.org/bugzilla/attachment.cgi?id=15422&action=edit proposed patch for binutils -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30569] MIPS16 function stub assertion fail for mipsel_24kc_24kf
https://sourceware.org/bugzilla/show_bug.cgi?id=30569 --- Comment #2 from Christian Marangi (Ansuel) --- (In reply to dianlujitao from comment #0) > When cross-compiling haproxy for openwrt mipsel_24kc_24kf, it throws the > following error when linking the final executable: > > - > make TARGET=linux-musl -C > /home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl.Linux-x86_64/ > build_dir/target-mipsel_24kc+24kf_musl/haproxy-ssl/haproxy-2.6.13 > DESTDIR="/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl. > Linux-x86_64/build_dir/target-mipsel_24kc+24kf_musl/haproxy-ssl/haproxy-2.6. > 13/ipkg-install" CC="mipsel-openwrt-linux-musl-gcc" > PCREDIR="/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl. > Linux-x86_64/staging_dir/target-mipsel_24kc+24kf_musl/usr/" USE_LUA=1 > LUA_LIB_NAME="lua5.3" > LUA_INC="/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl. > Linux-x86_64/staging_dir/target-mipsel_24kc+24kf_musl/usr/include/lua5.3" > LUA_LIB="/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl. > Linux-x86_64/staging_dir/target-mipsel_24kc+24kf_musl/usr/lib" > SMALL_OPTS="-DBUFSIZE=16384 -DMAXREWRITE=1030 -DSYSTEM_MAXCONN=165530" > USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_PTHREAD_PSHARED=1 USE_LIBATOMIC=1 > USE_PROMEX=1 VERSION="2.6.13" SUBVERS="-1" VERDATE="2023/06/14" IGNOREGIT=1 > USE_OPENSSL=1 ADDLIB="-lcrypto -lm" CFLAGS="-Os -pipe -mno-branch-likely > -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts > -ffile-prefix-map=/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3. > 0_musl.Linux-x86_64/build_dir/target-mipsel_24kc+24kf_musl/haproxy-ssl/ > haproxy-2.6.13=haproxy-2.6.13 -mips16 -minterlink-mips16 -Wformat > -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now > -Wl,-z,relro -fno-strict-aliasing -Wdeclaration-after-statement > -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered > -Wno-missing-field-initializers -Wno-cast-function-type > -Wno-address-of-packed-member -Wtype-limits -Wshift-negative-value > -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference -fwrapv > -fasynchronous-unwind-tables -Wno-null-dereference" > LD="mipsel-openwrt-linux-musl-gcc" > LDFLAGS="-L/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl. > Linux-x86_64/staging_dir/toolchain-mipsel_24kc+24kf_gcc-12.3.0_musl/usr/lib > -L/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl.Linux- > x86_64/staging_dir/toolchain-mipsel_24kc+24kf_gcc-12.3.0_musl/lib -znow > -zrelro" > make[3]: Entering directory > '/home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl.Linux- > x86_64/build_dir/target-mipsel_24kc+24kf_musl/haproxy-ssl/haproxy-2.6.13' > CC src/version.o > LD haproxy > /home/xxx/openwrt/openwrt-sdk-pistachio-generic_gcc-12.3.0_musl.Linux-x86_64/ > staging_dir/toolchain-mipsel_24kc+24kf_gcc-12.3.0_musl/bin/../lib/gcc/mipsel- > openwrt-linux-musl/12.3.0/../../../../mipsel-openwrt-linux-musl/bin/ld: BFD > (GNU Binutils) 2.40.0 assertion fail elfxx-mips.c:11278 > collect2: error: ld returned 1 exit status > make[3]: *** [Makefile:1011: haproxy] Error 1 > - > > Package makefile can be found at > https://github.com/openwrt/packages/blob/master/net/haproxy/Makefile > > All binutils releases after 2.37 are affected. After investigation I found > that the commit breaks linking is > https://sourceware.org/git/?p=binutils-gdb.git;a=commit; > h=6540edd52cc061071e1ad02c381e85de41bded1f Can you test the attached patch? I can confirm this bug and can be reproduced easily. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications
https://sourceware.org/bugzilla/show_bug.cgi?id=31460
--- Comment #1 from Vladimir Mezentsev
---
I cannot reproduce the problem on OL8 with libpthread-2.28.
It looks like calloc() is called in ./nptl/pthread_setspecific.c:69
But this calloc() must be from libc, not from the user application.
Can you run this test in your environment:
% cat t.c
#include
long long calloc = 0;
void *func(void *arg)
{
return NULL;
}
int main(int argc, char **argv)
{
pthread_t thr;
void *val;
pthread_create(&thr, NULL, func, NULL);
pthread_join(thr, &val);
return 0;
}
% gcc -pthread t.c
% ./a.out
--
You are receiving this mail because:
You are on the CC list for the bug.
