[Bug ld/31461] score-elf buffer overflow
https://sourceware.org/bugzilla/show_bug.cgi?id=31461 Alan Modra changed: What|Removed |Added Target||score-elf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31461] New: score-elf buffer overflow
https://sourceware.org/bugzilla/show_bug.cgi?id=31461 Bug ID: 31461 Summary: score-elf buffer overflow Product: binutils Version: 2.43 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: amodra at gmail dot com Target Milestone: --- score_elf_create_dynamic_relocation accesses rel[1] and rel[2] when there is no guarantee that there are relocs past rel[0]. Seen when running the ld testsuite on a number of tests, eg. ld-elf/pr26979a -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31454] Add constant tracking to disassembly (objdump -d, gdb disas)
https://sourceware.org/bugzilla/show_bug.cgi?id=31454 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31458] FAIL: MIPS eh-frame 3 with --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=31458 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- 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 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31460] New: heap tracing causes infinite recursion on calloc with multi-threaded applications
https://sourceware.org/bugzilla/show_bug.cgi?id=31460 Bug ID: 31460 Summary: heap tracing causes infinite recursion on calloc with multi-threaded applications Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: carlsonj at workingcode dot com Target Milestone: --- Created attachment 15391 --> https://sourceware.org/bugzilla/attachment.cgi?id=15391=edit Demonstrates infinite recursion with "-H on" When setting "-H on" with "gprofng collect app", starting a new thread triggers infinite recursion. The crash looks like this in gdb: #26129 0x7f81ed538de5 in calloc (size=32, esize=16) at heaptrace.c:447 #26130 0x7f81e7c9bbaf in ___pthread_setspecific (key=key@entry=38, value=value@entry=0x7f81e19fcac0) at ./nptl/pthread_setspecific.c:69 #26131 0x7f81ed40bff7 in __collector_tsd_get_by_key (key_index=) at tsd.c:138 #26132 0x7f81ed538de5 in calloc (size=32, esize=16) at heaptrace.c:447 #26133 0x7f81e7c9bbaf in ___pthread_setspecific (key=key@entry=38, value=value@entry=0x7f81e19fcad0) at ./nptl/pthread_setspecific.c:69 #26134 0x7f81ed40bff7 in __collector_tsd_get_by_key (key_index=) at tsd.c:138 #26135 0x7f81ed538de5 in calloc (size=32, esize=16) at heaptrace.c:447 #26136 0x7f81e7c9bbaf in ___pthread_setspecific (key=key@entry=40, value=value@entry=0x7f81e19fcae0) at ./nptl/pthread_setspecific.c:69 #26137 0x7f81ed40bff7 in __collector_tsd_get_by_key (key_index=) at tsd.c:138 #26138 0x7f81ed428bfc in __collector_ext_unwind_key_init (isPthread=isPthread@entry=1, stack=stack@entry=0x0) at unwind.c:342 #26139 0x7f81ed40552a in collector_root (cargs=) at dispatcher.c:1103 #26140 0x7f81e7c94ac3 in start_thread (arg=) at ./nptl/pthread_create.c:442 #26141 0x7f81e7d26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Attached is a simple program that demonstrates the problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31458] FAIL: MIPS eh-frame 3 with --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=31458 --- Comment #1 from H.J. Lu --- Created attachment 15390 --> https://sourceware.org/bugzilla/attachment.cgi?id=15390=edit A patch Please feel free to take over this patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31459] New: need a way to suppress the stderr message
https://sourceware.org/bugzilla/show_bug.cgi?id=31459 Bug ID: 31459 Summary: need a way to suppress the stderr message Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: carlsonj at workingcode dot com Target Milestone: --- In the old Oracle Performance Analyzer system, I could use "-O" to redirect the 'collect' output to a file. In the new "gprofng collect app" tool, "-O" now means "place the .er output here." That change in gprofng is very helpful indeed, but leaves me without a way to get rid of the stderr output (particularly the "Creating experiment directory" message), which ends up interfering with some of the automated tools I'm using. Would it be possible to bring back redirection for output from the tool itself or perhaps add a "-q" (quiet) option? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31458] New: FAIL: MIPS eh-frame 3 with --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=31458 Bug ID: 31458 Summary: FAIL: MIPS eh-frame 3 with --no-keep-memory Product: binutils Version: 2.43 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: macro at orcam dot me.uk, paul.hua.gm at gmail dot com Target Milestone: --- Target: mipstx39-elf When --no-keep-memory is enabled, mipstx39-elf reports: FAIL: MIPS eh-frame 3 due to this code in bfd/elfxx-mips.c:_bfd_mips_elf_eh_frame_address_size to fail: if (sec->reloc_count > 0 && elf_section_data (sec)->relocs != NULL && (ELF32_R_TYPE (elf_section_data (sec)->relocs[0].r_info) == R_MIPS_64)) return 8; elf_section_data (sec)->relocs is NULL with --no-keep-memory. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31327] libbacktrace test failures
https://sourceware.org/bugzilla/show_bug.cgi?id=31327 --- Comment #3 from Ian Lance Taylor --- It's fine with me. I don't know if there is any binutils policy about this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31456] New: readelf: SEGV in read_leb128
https://sourceware.org/bugzilla/show_bug.cgi?id=31456 Bug ID: 31456 Summary: readelf: SEGV in read_leb128 Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: chkunq at gmail dot com Target Milestone: --- Created attachment 15388 --> https://sourceware.org/bugzilla/attachment.cgi?id=15388=edit A zip archive containing the input files to trigger the bug Dear All, This bug was found on Ubuntu 20.04 64-bit & binutils was checked out from main repository at git://sourceware.org/git/binutils-gdb.git. Its commit is 5b95198e2e40b0301d37d989edc344a334c26b12 (Thu, 7 Mar 2024 00:00:53). binutils was built with ASAN using clang-14. The configure command was: CC=clang CFLAGS="-DFORTIFY_SOURCE -fstack-protector-all -fsanitize=address -fno-omit-frame-pointer -g -Wno-error" ../configure --disable-shared --disable-gdb --disable-libdecnumber --disable-readline --disable-sim To reproduce: Download and unzip the attached zip archive, and get POCs readelf -w [poc_file] ASAN says: ==2829534==ERROR: AddressSanitizer: SEGV on unknown address 0x5021010101da (pc 0x0056213d bp 0x00782da0 sp 0x7ffdaff86770 T0) ==2829534==The signal is caused by a READ memory access. #0 0x56213d in read_leb128 /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/dwarf.c:289:28 #1 0x56213d in display_debug_names /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/dwarf.c:10759:8 #2 0x4be79d in display_debug_section /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:16950:18 #3 0x4be79d in process_section_contents /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:17046:10 #4 0x471fa3 in process_object /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:23160:9 #5 0x46b2d4 in process_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:23583:13 #6 0x46b2d4 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/readelf.c:23654:11 #7 0x7ff763b87082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 #8 0x37225d in _start (/data/symccgo/bug/binutils/obj-asan/binutils/readelf+0x37225d) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/dwarf.c:289:28 in read_leb128 ==2829534==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31457] New: strip: SEGV in copy_archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31457 Bug ID: 31457 Summary: strip: SEGV in copy_archive Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: chkunq at gmail dot com Target Milestone: --- Created attachment 15389 --> https://sourceware.org/bugzilla/attachment.cgi?id=15389=edit A zip archive containing the input files to trigger the bug Dear All, This bug was found on Ubuntu 20.04 64-bit & binutils was checked out from main repository at git://sourceware.org/git/binutils-gdb.git. Its commit is 5b95198e2e40b0301d37d989edc344a334c26b12 (Thu, 7 Mar 2024 00:00:53). binutils was built with ASAN using clang-14. The configure command was: CC=clang CFLAGS="-DFORTIFY_SOURCE -fstack-protector-all -fsanitize=address -fno-omit-frame-pointer -g -Wno-error" ../configure --disable-shared --disable-gdb --disable-libdecnumber --disable-readline --disable-sim To reproduce: Download and unzip the attached zip archive, and get POCs strip-new --strip-all -o /dev/null [poc_file] ASAN says: ==2468890==ERROR: AddressSanitizer: SEGV on unknown address 0x00f0 (pc 0x003e5972 bp 0x7ffd4c9d0d20 sp 0x7ffd4c9d09e0 T0) ==2468890==The signal is caused by a WRITE memory access. ==2468890==Hint: address points to the zero page. #0 0x3e5972 in copy_archive /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3798:8 #1 0x3e5972 in copy_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3956:7 #2 0x3e2513 in strip_main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:4973:7 #3 0x3e2513 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6173:5 #4 0x7f32cec7f082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 #5 0x31eeed in _start (/data/symccgo/bug/binutils/obj-asan/binutils/strip-new+0x31eeed) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3798:8 in copy_archive ==2468890==ABORTING It's worth mentioning that this bug cannot be stably reproduced 100% in one attempt; it might require multiple attempts to replicate. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31455] New: objcopy: invalid-free in bfd_init_section_compress_status
https://sourceware.org/bugzilla/show_bug.cgi?id=31455 Bug ID: 31455 Summary: objcopy: invalid-free in bfd_init_section_compress_status Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: chkunq at gmail dot com Target Milestone: --- Created attachment 15387 --> https://sourceware.org/bugzilla/attachment.cgi?id=15387=edit A zip archive containing the input files to trigger the bug Dear All, This bug was found on Ubuntu 20.04 64-bit & binutils was checked out from main repository at git://sourceware.org/git/binutils-gdb.git. Its commit is 5b95198e2e40b0301d37d989edc344a334c26b12 (Thu, 7 Mar 2024 00:00:53). binutils was built with ASAN using clang-14. The configure command was: CC=clang CFLAGS="-DFORTIFY_SOURCE -fstack-protector-all -fsanitize=address -fno-omit-frame-pointer -g -Wno-error" ../configure --disable-shared --disable-gdb --disable-libdecnumber --disable-readline --disable-sim To reproduce: Download and unzip the attached zip archive, and get POCs objcopy --compress-debug-sections [poc_file] /dev/null ASAN says: ==953211==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x621066f0 in thread T0 #0 0x3a19a2 in free /data/symccgo/bug/llvm-14-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3 #1 0x4a4c2c in bfd_init_section_compress_status /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/compress.c:1092:7 #2 0x5cb9eb in _bfd_elf_make_section_from_shdr /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/elf.c:1222:9 #3 0x5cefb1 in bfd_section_from_shdr /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/elf.c:3060:11 #4 0x764c93 in bfd_elf32_object_p /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/elfcode.h:880:7 #5 0x4afd2d in bfd_check_format_matches /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/format.c:437:17 #6 0x3e3f9d in copy_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3958:12 #7 0x3ed53c in copy_main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6074:3 #8 0x3e12d9 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6175:5 #9 0x7fb550494082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 #10 0x31eeed in _start (/data/symccgo/bug/binutils/obj-asan/binutils/objcopy+0x31eeed) 0x621066f0 is located 496 bytes inside of 4064-byte region [0x62106500,0x621074e0) allocated by thread T0 here: #0 0x3a1c4e in malloc /data/symccgo/bug/llvm-14-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 #1 0xa05b4b in _objalloc_alloc /data/symccgo/bug/binutils/obj-asan/libiberty/../../binutils-gdb/libiberty/objalloc.c:159:41 #2 0x4afd2d in bfd_check_format_matches /data/symccgo/bug/binutils/obj-asan/bfd/../../binutils-gdb/bfd/format.c:437:17 #3 0x3e3f9d in copy_file /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:3958:12 #4 0x3ed53c in copy_main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6074:3 #5 0x3e12d9 in main /data/symccgo/bug/binutils/obj-asan/binutils/../../binutils-gdb/binutils/objcopy.c:6175:5 #6 0x7fb550494082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 SUMMARY: AddressSanitizer: bad-free /data/symccgo/bug/llvm-14-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3 in free ==2639543==ABORTING Moreover, objcopy (compiled by clang-14 -O0) crashes even without ASAN, as follows: free(): invalid pointer Aborted (core dumped) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31327] libbacktrace test failures
https://sourceware.org/bugzilla/show_bug.cgi?id=31327 Sam James changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ian at airs dot com, ||nickc at redhat dot com See Also||https://github.com/ianlance ||taylor/libbacktrace/issues/ ||118 Resolution|WORKSFORME |--- --- Comment #2 from Sam James --- OK, I get what's happening here. This ended up being https://github.com/ianlancetaylor/libbacktrace/issues/118 which is fixed upstream. Nick, or Ian, could we sync the version in binutils-gdb.git with upstream please? I am happy to do it with permission too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31454] New: Add constant tracking to disassembly (objdump -d, gdb disas)
https://sourceware.org/bugzilla/show_bug.cgi?id=31454
Bug ID: 31454
Summary: Add constant tracking to disassembly (objdump -d, gdb
disas)
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
Consider
unsigned foo (void) { return 0xdeadbeefU; }
unsigned long long bar (void) { return 0xdeadbeefcafebabeULL; }
static int p;
int *baz (void) { return }
int main () {}
When linked on x86_64 with -O2 -fpic, objdump -d and gdb disassemble already
does some
immediate visualization to help user reading the code:
00401140 :
401140: 48 8d 05 d9 2e 00 00lea0x2ed9(%rip),%rax#
404020 <__TMC_END__>
401147: c3 ret
or
Dump of assembler code for function baz:
0x00401140 <+0>: lea0x2ed9(%rip),%rax# 0x404020
0x00401147 <+7>: ret
knows to handle lea with immediate and (%rip) to add the 0x2ed9 in there with
end of the instruction and print the resulting immediate and perhaps symbolic
rendering of it in the comment.
The 0xdeadbeef and 0xdeadbeefcafebabe immediates are clearly shown in the
assembly, so there is no need to help users reading that.
Now, let's try the same on other arches, e.g. aarch64:
400140: 5297dde0mov w0, #0xbeef //
#48879
400144: 72bbd5a0movkw0, #0xdead, lsl #16
in foo,
400160: d29757c0mov x0, #0xbabe //
#47806
400164: f2b95fc0movkx0, #0xcafe, lsl #16
400168: f2d7dde0movkx0, #0xbeef, lsl #32
40016c: f2fbd5a0movkx0, #0xdead, lsl #48
in bar and
400180: f0e0adrpx0, 41f000
400184: 913fa000add x0, x0, #0xfe8
in baz. It would be helpful if the disassembly could for a small set of
instructions which are usually involved in constant creations in GPR registers
be able to propagate constants through them; for each GPR register remember if
it is set to a known constant (then also the constant value) or not. When
seeing a start of a function (new symbol?)
reset this knowledge, maybe also reset it on possible conditional/unconditional
jump destinations from the same function (though computing that might require
another pass through the instructions), when seeing a GPR register set with a
handled instruction to constant remember that constant, when seeing a handled
instruction where all the inputs
have known constant values try to evaluate the instruction and remember the
resulting constant and then show in comments like in the lea case above the
immediate plus symbolic rendering if any. And when seeing an unhandled
instruction that sets or clobbers some GPR (or might do that), forget the value
of that register.
So, for foo above, remember that w0 is set to 0xbeef, interpret the movk
instruction that the result is 0xdeadbeef and tell it to the user, ditto for
the second case, similarly remember for adrp and handle the add too, printing
there 41ffe8 .
Now, repeat this on other arches, powerpc{,64,64le}, sparc{,64}, ...
On s390x, one can also see that it loads some constants from
.rodata/.data.rel.ro* and similar sections, those too would be nice to track
and print.
This would help users so that they don't have to scratch their heads
interpreting the instructions or having to actually see what it does at runtime
to find out what it actually computes.
In gdb, sometimes one just disassembles part of a function, not the whole one,
I think it would be perfectly fine to start with nothing known state at the
start of such a block and print only what is discovered in that block.
--
You are receiving this mail because:
You are on the CC list for the bug.
