[Bug ld/30259] RISC-V: Assertion failed when trying to link from "code" section
https://sourceware.org/bugzilla/show_bug.cgi?id=30259 Nelson Chu changed: What|Removed |Added CC||nelsonc1225 at sourceware dot org --- Comment #1 from Nelson Chu --- A quick look, but not in details, the problem caused by that the .section code must add at least "a" alloca attribute. Otherwise, ld even not go into check_reloc, so that we won't do any GOT stuffs for R_RISCV_HI20, but will try to use it in relocate_section. This may also be one of the cases that show the non-matching between check_reloc and relocate_section. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30282] New: risc-v: objdump îs really slow
https://sourceware.org/bugzilla/show_bug.cgi?id=30282 Bug ID: 30282 Summary: risc-v: objdump îs really slow Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nelsonc1225 at sourceware dot org Target Milestone: --- Originally discussion, https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30282] risc-v: objdump is really slow
https://sourceware.org/bugzilla/show_bug.cgi?id=30282 Nelson Chu changed: What|Removed |Added Summary|risc-v: objdump îs really |risc-v: objdump is really |slow|slow -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30282] risc-v: objdump is really slow
https://sourceware.org/bugzilla/show_bug.cgi?id=30282 --- Comment #1 from Nelson Chu --- Created attachment 14785 --> https://sourceware.org/bugzilla/attachment.cgi?id=14785&action=edit Proposed solution v1 I guess the massive dis-assembler slowdown is caused by searching the mapping symbol, so I try to re-write the code to increase the dump. Please see the attached for the details, and and FIXME there should be a better solution. Anyway, it did not see significant improvement when running the gcc regression again... So maybe it just work for some special cases, or still have other reason that slow down the whole thing, not really sure about that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30282] risc-v: objdump is really slow
https://sourceware.org/bugzilla/show_bug.cgi?id=30282 Nelson Chu changed: What|Removed |Added Attachment #14785|0 |1 is patch|| Attachment #14785|application/mbox|text/plain mime type|| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30279] UBSAN error: /buildworker/marxinbox-cross-binutils-sanitizers/build/gas/config/tc-m68hc11.c:708:20
https://sourceware.org/bugzilla/show_bug.cgi?id=30279 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c61b7b7b8ea5e3a55b4642dade4798e5c896df66 commit c61b7b7b8ea5e3a55b4642dade4798e5c896df66 Author: Alan Modra Date: Tue Mar 28 20:25:26 2023 +1030 Avoid undefined behaviour in m68hc11 md_begin Given p = A where p is a pointer to some type and A is an array of that type, then the expression p - 1 + 1 evokes undefined behaviour according to the C standard. gcc-13 -fsanitize=address,undefined complains about this, but not where the undefined behaviour actually occurs at tc-m68hc11.c:646. Instead you get an error: "tc-m68hc11.c:708:20: runtime error: store to address 0x6260016c with insufficient space for an object of type 'int'". Which is a lie. There most definitely is space there. Oh well, diagnostics are sometimes hard to get right. The UB is easy to avoid. PR 30279 * config/tc-m68hc11.c (md_begin): Avoid undefined pointer decrement. Remove unnecessary cast. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30279] UBSAN error: /buildworker/marxinbox-cross-binutils-sanitizers/build/gas/config/tc-m68hc11.c:708:20
https://sourceware.org/bugzilla/show_bug.cgi?id=30279 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |2.41 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |RESOLVED --- Comment #5 from Alan Modra --- Fixed for 2.41. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 57366 in oss-fuzz: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite
Updates: Labels: -restrict-view-commit Comment #3 on issue 57366 by sheriffbot: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57366#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 57457 in oss-fuzz: binutils:fuzz_addr2line: Direct-leak in comp_unit_maybe_decode_line_info
Updates: Labels: -restrict-view-commit Comment #3 on issue 57457 by sheriffbot: binutils:fuzz_addr2line: Direct-leak in comp_unit_maybe_decode_line_info https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57457#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug gprofng/30281] error: multiple definition of `pwrite@GLIBC_2.2'; on i586-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=30281 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Vladimir Mezentsev --- I don't have SUSE Linux. But I can reproduce the similar problem on OL9. When I build libgp-sync.so (synctrace.) with -flto=auto or -flto=1, I see: <>/synctrace.c:669: multiple definition of `pthread_cond_wait' /bin/ld: /tmp/ccw8LL6P.ltrans0.ltrans.o: in function `pthread_cond_timedwait': <>/synctrace.c:720: multiple definition of `pthread_cond_timedwait' /bin/ld: /tmp/ccw8LL6P.ltrans0.ltrans.o: in function `pthread_join': <>/synctrace.c:768: multiple definition of `pthread_join' /bin/ld: /tmp/ccw8LL6P.ltrans0.ltrans.o: in function `sem_wait': <>/synctrace.c:816: multiple definition of `sem_wait' collect2: error: ld returned 1 exit status It looks like a compiler bug. But I don't know yet what a real problem is. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30281] error: multiple definition of `pwrite@GLIBC_2.2'; on i586-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=30281
--- Comment #2 from Vladimir Mezentsev
---
See also Bug 30006 - Failure to build binutils-2.40 gprofng using gold
I use OL9 and gcc-11:
% uname -a
Linux localhost.localdomain 5.15.0-0.30.1.el9uek.x86_64 #2 SMP Mon Mar 21
14:34:58 PDT 2022 x86_64 x86_64 x86_64 GNU/Linux
% gcc --version
gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-2.2.0.3)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This small test demonstrates a problem:
% cat -n my.ver
1 GLIBC_2.1 {
2global:
3 myfunc;
4 } ;
5
% cat -n x.c
1 #ifdef USE_ASM
2 __asm__(".symver myfunc_2_1,myfunc@GLIBC_2.1");
3 #else
4 __attribute__ ((__symver__ ("myfunc@GLIBC_2.1")))
5 #endif
6 int myfunc_2_1 () { return 1; }
7
8 int myfunc () { return 1; }
9
I need to create a library with two functions: myfunc and myfunc@GLIBC_2.1:
1. "-fuse-ld=gold" failed:
% gcc -fuse-ld=gold -shared x.c -fPIC -DPIC -Wl,--version-script
-Wl,./my.ver -o libx.so
/bin/ld.gold: error: /tmp/cc9P7FqS.o: multiple definition of 'myfunc'
/bin/ld.gold: /tmp/cc9P7FqS.o: previous definition here
collect2: error: ld returned 1 exit status
2. "-fuse-ld=bfd -flto=auto" (or -flto=1) failed:
% gcc -fuse-ld=bfd -flto=auto -shared x.c -fPIC -DPIC -Wl,--version-script
-Wl,./my.ver -o libx.so
/bin/ld.bfd: /tmp/cc5Hhpvl.ltrans0.ltrans.o: in function `myfunc':
:(.text+0xb): multiple definition of `myfunc'
collect2: error: ld returned 1 exit status
3. "-DUSE_ASM -fuse-ld=bfd -flto=auto" passed:
% gcc -DUSE_ASM -fuse-ld=bfd -flto=auto -shared x.c -fPIC -DPIC
-Wl,--version-script -Wl,./my.ver -o libx.so
4. -fuse-ld=bfd without -flto passed too:
% gcc -DUSE_ASM -fuse-ld=bfd -shared x.c -fPIC -DPIC -Wl,--version-script
-Wl,./my.ver -o libx.so
% gcc -fuse-ld=bfd -shared x.c -fPIC -DPIC -Wl,--version-script -Wl,./my.ver
-o libx.so
It looks like a compiler/ld bug.
The workaround is to configure a build with "-fuse-ld=bfd" and without -flto.
--
You are receiving this mail because:
You are on the CC list for the bug.
