[Bug binutils/29497] New: `x86_64-w64-mingw32-dlltool -m i386` doesn't produce a fully i386 importlib
https://sourceware.org/bugzilla/show_bug.cgi?id=29497 Bug ID: 29497 Summary: `x86_64-w64-mingw32-dlltool -m i386` doesn't produce a fully i386 importlib Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: mh-sourceware at glandium dot org Target Milestone: --- ``` $ cat
Issue 48401 in oss-fuzz: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite
Updates: Labels: -restrict-view-commit Comment #3 on issue 48401 by sheriffbot: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48401#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 47471 in oss-fuzz: binutils:fuzz_addr2line: Timeout in fuzz_addr2line
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 47471 by sheriffbot: binutils:fuzz_addr2line: Timeout in fuzz_addr2line https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47471#c3 This bug has exceeded our disclosure deadline. 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/29465] [docs] File version.texi is created in the binutils source directory
https://sourceware.org/bugzilla/show_bug.cgi?id=29465 --- Comment #1 from Ruud van der Pas --- After exploring several alternatives, it was decided to no longer dynamically generate file version.texi. Instead, the information in version.texi will be updated as part of a patch for the documentation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29476] gprofng.texi makeinfo build failure on centos 7
https://sourceware.org/bugzilla/show_bug.cgi?id=29476 --- Comment #3 from nightstrike --- (In reply to Vladimir Mezentsev from comment #2) > We need makeinfo 6.5 or newer. Yup. I pointed to this in the first post, that the method used to exclude the use of earlier versions doesn't work. > What is an output of `makeinfo --version` on your machine ? I showed this in the first post as the output of rpm -q, but here it is: $ makeinfo --version makeinfo (GNU texinfo) 5.1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29476] gprofng.texi makeinfo build failure on centos 7
https://sourceware.org/bugzilla/show_bug.cgi?id=29476 Kurt Goebel changed: What|Removed |Added Priority|P3 |P2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29465] [docs] File version.texi is created in the binutils source directory
https://sourceware.org/bugzilla/show_bug.cgi?id=29465 Kurt Goebel changed: What|Removed |Added CC||kurt.goebel at oracle dot com Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29476] gprofng.texi makeinfo build failure on centos 7
https://sourceware.org/bugzilla/show_bug.cgi?id=29476 Kurt Goebel changed: What|Removed |Added CC||kurt.goebel at oracle dot com Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29362] Some memory leaks occur when binutils code is tested using the binutils fuzz test suite.
https://sourceware.org/bugzilla/show_bug.cgi?id=29362 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Alan Modra --- Thanks for the patches! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29362] Some memory leaks occur when binutils code is tested using the binutils fuzz test suite.
https://sourceware.org/bugzilla/show_bug.cgi?id=29362 --- 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=450da4bd38ae529a6879baafe59b1e88507b5fd9 commit 450da4bd38ae529a6879baafe59b1e88507b5fd9 Author: Alan Modra Date: Tue Aug 16 00:16:49 2022 +0930 PR29362, some binutils memory leaks 2022-08-16 Alan Modra Cunlong Li PR 29362 * dwarf.c (free_debug_information): New function, extracted.. (free_debug_memory): ..from here. (process_debug_info): Use it when before clearing out unit debug_information. Clear all fields. * objcopy.c (delete_symbol_htabs): New function. (main): Call it via xatexit. (copy_archive): Free "dir". * objdump.c (free_debug_section): Free reloc_info. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29494] New: Trailing jump table leads to "Error: unaligned opcodes detected in executable segment" on ARM thumb
https://sourceware.org/bugzilla/show_bug.cgi?id=29494
Bug ID: 29494
Summary: Trailing jump table leads to "Error: unaligned opcodes
detected in executable segment" on ARM thumb
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: gus at projectgus dot com
Target Milestone: ---
Created attachment 14281
--> https://sourceware.org/bugzilla/attachment.cgi?id=14281=edit
ltrans assembler listing that exhibits the problem
When LTO is enabled then it's possible for gcc to generate a jump table where
the table data is the last thing in its executable section. (i.e. all of the
jump table entries point to offsets earlier in the section, and no other
instructions appear after it.)
On ARM thumb (min 2 byte instructions), if a jump table with single byte
entries has an odd number of entries then the section ends at an odd numbered
offset.
If also generating DWARF debug info, it appears the check in gas/dwarf2db.c
scale_addr_delta() will then fail with "unaligned opcodes detected in
executable segment".
However, the assembly listing is otherwise correct.
I ran across this in the MicroPython project, with a code snippet in
objint_mpz.c:315 as follows:
...
switch (op) {
case MP_BINARY_OP_LESS:
return mp_obj_new_bool(cmp < 0);
case MP_BINARY_OP_MORE:
return mp_obj_new_bool(cmp > 0);
case MP_BINARY_OP_LESS_EQUAL:
return mp_obj_new_bool(cmp <= 0);
case MP_BINARY_OP_MORE_EQUAL:
return mp_obj_new_bool(cmp >= 0);
case MP_BINARY_OP_EQUAL:
return mp_obj_new_bool(cmp == 0);
default:
return MP_OBJ_NULL; // op not supported
}
}
With -Os and no LTO, gcc 12.1 generates a jump table, and emits more assembly
after it:
...
.loc 1 315 9 view .LVU1204
bl __gnu_thumb1_case_uqi
.L105:
.byte (.L109-.L105)/2
.byte (.L108-.L105)/2
.byte (.L107-.L105)/2
.byte (.L106-.L105)/2
.byte (.L104-.L105)/2
.p2align 1
.L109:
.loc 1 317 17 is_stmt 1 view .LVU1205
.LVL211:
.LBB240:
.LBI237:
.loc 3 781 24 view .LVU1206
.LBB239:
.loc 3 782 5 view .LVU1207
.loc 3 782 30 is_stmt 0 view .LVU1208
cmp r3, #0
blt .LCB2415
b .L70@long jump
...
With LTO enabled, the local translations further optimise and rearrange until
the jump table appears at the end of the executable listing for the enclosing
function and section:
...
.LBB303:
.loc 2 315 9 is_stmt 1 view .LVU1105
ldr r2, [sp, #16]
cmp r2, #4
bhi .L13
movsr0, r2
bl __gnu_thumb1_case_sqi
.L111:
.byte (.L109-.L111)/2
.byte (.L108-.L111)/2
.byte (.L118-.L111)/2
.byte (.L106-.L111)/2
.byte (.L104-.L111)/2
.LBE303:
.cfi_endproc
.LFE0:
.size mp_obj_int_binary_op, .-mp_obj_int_binary_op
.text
.Letext0:
.file 10 ""
.section.debug_info,"",%progbits
...
As a result, the executable section ends with an odd length, and linking fails
due to the assembler DWARF generation error:
build-NUCLEO_F091RC/firmware.elf.ltrans1932.ltrans.s: Assembler messages:
build-NUCLEO_F091RC/firmware.elf.ltrans1932.ltrans.s: Error: unaligned opcodes
detected in executable segment
make[1]: *** [/tmp/ccfzQYxO.mk:3866:
build-NUCLEO_F091RC/firmware.elf.ltrans1932.ltrans.o] Error 1
Manually running "arm-none-eabi-as firmware.elf.ltrans1932.ltrans.s" produces
the same error, and inserting a padding ".byte 0" in the listing after the jump
table will fix the error.
It might be the case that this is gcc's fault for generating an executable
section with an odd length, but given the table is the last thing in the
section it seems reasonable not to pad it.
Indeed, if "-g" isn't passed to the compiler then the assembler produces valid
binary code and everything works, it's only DWARF generation which fails.
I am wondering if a suitable patch would be to ignore this check if there are
no additional opcodes following the odd offset, i.e. ignore the failure
condition if it's positioned at the end of a section. If so, I'm happy to try
and write that patch. However, I'm not very familiar with gas or DWARF so I'm
guessing it might be much more complex than this!
Looks like I can only attach one file, so rather than an archive I've attached
the ltrans assembler listing which exhibits the issue. If it's helpful then I
can provide more example files, or write a simpler assembler listing to
reproduce.
Thanks in advance for any insights!
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29495] New: Bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=29495 Bug ID: 29495 Summary: Bug report Product: binutils Version: 2.40 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sophrosx at gmail dot com Target Milestone: --- Created attachment 14282 --> https://sourceware.org/bugzilla/attachment.cgi?id=14282=edit testcases for strip-new Hello, I detected some new memory leak and dead loop problems through fuzz testing, which I think may be a vulnerability. The configuration of binutils is: $ ./configure --disable-shared && make -j and compiled with gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 I use the program strip-new in "~/binutils-gdb/binutils/strip-new" in master branch[https://github.com/bminor/binutils-gdb/tree/master] with parameter "-o tmp ./testcase", and after waiting 20 minutes, the program neither giving any outputs nor terminating. What is more, the program strip-new occupied all the memory. The testcase that trigger such results are in the attachment. If there is anything I am unclear about or need to discuss further, please feel free to contact me~ Looking forward to your reply! Thanks & Best Regards -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29075] objdump -S does not support debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=29075 --- Comment #18 from Nick Clifton --- Hi Aaron, >> The other issue is finding the time to actually write this code. If someone >> is volunteering then I would be very happy to leave it to them ... :-) > > I'll take a look at this Thanks! That would be most appreciated. If you have any questions please feel free to ask. > and try to keep any additional debuginfod support > contained in objdump. That would be my preference too. If possible it might be best to put most of the new code into binutils/dwarf.c since that is turning into a sort of bfd-free library for the DWARF needs of the binutils tools. So any improvements might help other tools like readelf or addr2line. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29362] Some memory leaks occur when binutils code is tested using the binutils fuzz test suite.
https://sourceware.org/bugzilla/show_bug.cgi?id=29362 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Last reconfirmed||2022-08-15 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29492] program nm-new bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=29492 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Alan Modra --- The endless looping is all in the rust demangler. Please report these bugs to the gcc project at https://gcc.gnu.org/bugzilla/ It is helpful to report the symbols being demangled rather than supply object files. They are: 1) _RYXBAL_OFFGLOBTABLE_ 2) _RYFGNUSLT_FHStNB10ay_start 3) _RYDGLOBOFFSET_TABLE_ 4) _RYFGDIC6gnu_compilediBtOhighlightEH_FRAME_HDR 5) _RYFUDGC6ShigdefaulttiBtOhighlightEH_FRAME_HDR 6) _RYFUDGC6Shighdignu_compiledhlightEH_FRAME_HDR 7) _RYFIMYeB_xDGLtSarray_start 8) _RYdMMYTopFinFGAarral_start 9) _RMYADGC0hdpnit_Grray_start 10) _RYNSMICu2FiFGtDBrray_s 11) _RYTOdPjesistePDGC1onRLab_e 12) _RIYADGO0Rdpnit_Grray_start -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29492] program nm-new bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=29492 --- Comment #2 from Shuang Po --- (In reply to Alan Modra from comment #1) > The endless looping is all in the rust demangler. Please report these bugs > to the gcc project at https://gcc.gnu.org/bugzilla/ > > It is helpful to report the symbols being demangled rather than supply > object files. They are: > 1) _RYXBAL_OFFGLOBTABLE_ > 2) _RYFGNUSLT_FHStNB10ay_start > 3) _RYDGLOBOFFSET_TABLE_ > 4) _RYFGDIC6gnu_compilediBtOhighlightEH_FRAME_HDR > 5) _RYFUDGC6ShigdefaulttiBtOhighlightEH_FRAME_HDR > 6) _RYFUDGC6Shighdignu_compiledhlightEH_FRAME_HDR > 7) _RYFIMYeB_xDGLtSarray_start > 8) _RYdMMYTopFinFGAarral_start > 9) _RMYADGC0hdpnit_Grray_start > 10) _RYNSMICu2FiFGtDBrray_s > 11) _RYTOdPjesistePDGC1onRLab_e > 12) _RIYADGO0Rdpnit_Grray_start Thank you~ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29491] program strip-new bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=29491 --- Comment #2 from Shuang Po --- (In reply to Alan Modra from comment #1) > Fixed with commit ef186fe54aa Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29492] New: program nm-new bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=29492 Bug ID: 29492 Summary: program nm-new bug report Product: binutils Version: 2.40 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sophrosx at gmail dot com Target Milestone: --- Created attachment 14280 --> https://sourceware.org/bugzilla/attachment.cgi?id=14280=edit nm-new testcases Hello, I detected the memory leak and dead loop problems through fuzz testing, which I think be a vulnerability. The configuration of binutils is: $ ./configure --disable-shared && make -j and compiled with gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 I use the program nm-new in ~/binutils-gdb/binutils/nm-new with parameter "-C ./dead_loop_input", and after waiting 1 hours, the program neither giving any outputs nor terminating. What is more, the program nm-new occupied all the memory. The testcase that trigger such results are in the attachment. Thanks & Best Regards -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29362] Some memory leaks occur when binutils code is tested using the binutils fuzz test suite.
https://sourceware.org/bugzilla/show_bug.cgi?id=29362 --- Comment #3 from Cunlong Li --- Created attachment 14279 --> https://sourceware.org/bugzilla/attachment.cgi?id=14279=edit Fix some memory leaks in dwarf.c and objdump.c I try to fix memory leak about free_debug_. Please check it out -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29362] Some memory leaks occur when binutils code is tested using the binutils fuzz test suite.
https://sourceware.org/bugzilla/show_bug.cgi?id=29362 --- Comment #2 from Cunlong Li --- Created attachment 14278 --> https://sourceware.org/bugzilla/attachment.cgi?id=14278=edit Fix memory leak in objcopy.c Fix memory leak in objcopy.c Please check it out. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29491] program strip-new bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=29491 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Alan Modra --- Fixed with commit ef186fe54aa -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29362] Some memory leaks occur when binutils code is tested using the binutils fuzz test suite.
https://sourceware.org/bugzilla/show_bug.cgi?id=29362 --- Comment #1 from Cunlong Li --- Created attachment 14277 --> https://sourceware.org/bugzilla/attachment.cgi?id=14277=edit Fix some memory leaks in objcopy.c I try to fix memory leak about symbol_htabs in objcopy. Please check it out -- You are receiving this mail because: You are on the CC list for the bug.
