Issue 57055 in oss-fuzz: binutils:fuzz_as: Direct-leak in xmalloc
Updates: Labels: Deadline-Approaching Comment #2 on issue 57055 by sheriffbot: binutils:fuzz_as: Direct-leak in xmalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57055#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - 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 binutils/30508] warning: empty loadable segment detected at vaddr=0x400000, is this intentional?
https://sourceware.org/bugzilla/show_bug.cgi?id=30508 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c5e824b9cee93a987a77906240c509add260a0d commit 3c5e824b9cee93a987a77906240c509add260a0d Author: H.J. Lu Date: Mon Jun 5 09:32:12 2023 -0700 ELF: Add "#pass" to ld-elf/pr30508.d Add "#pass" to ld-elf/pr30508.d to allow extra segments. PR binutils/30508 * testsuite/ld-elf/pr30508.d: Add "#pass". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30513] nm-new hangs infinitly on a special test case.
https://sourceware.org/bugzilla/show_bug.cgi?id=30513 --- Comment #2 from 孙文举 --- (In reply to Alan Modra from comment #1) > This is a problem demangling the rust symbol _RYODGYODGpe__RYODGpe. > Please report rust demangler bugs to https://gcc.gnu.org/bugzilla/ okey! thx for reply! I report the bug to rust demangling -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30508] warning: empty loadable segment detected at vaddr=0x400000, is this intentional?
https://sourceware.org/bugzilla/show_bug.cgi?id=30508 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |2.41 Resolution|--- |FIXED --- Comment #2 from H.J. Lu --- Fixed for 2.41. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30508] warning: empty loadable segment detected at vaddr=0x400000, is this intentional?
https://sourceware.org/bugzilla/show_bug.cgi?id=30508 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3f60b98298fd77dec3a9182797c9dd6d7796bcaf commit 3f60b98298fd77dec3a9182797c9dd6d7796bcaf Author: H.J. Lu Date: Fri Jun 2 11:54:21 2023 -0700 ELF: Don't warn an empty PT_LOAD with the program headers When rewriting the program headers, don't warn an empty PT_LOAD with the program headers. bfd/ PR binutils/30508 * elf.c (rewrite_elf_program_header): Don't warn if an empty PT_LOAD contains the program headers. ld/ PR binutils/30508 * testsuite/ld-elf/pr30508.d: New file. * testsuite/ld-elf/pr30508.s: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30374] ld: Add --remap-inputs-file= to remap input files
https://sourceware.org/bugzilla/show_bug.cgi?id=30374 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|NEW |ASSIGNED --- Comment #2 from Nick Clifton --- Created attachment 14918 --> https://sourceware.org/bugzilla/attachment.cgi?id=14918=edit Proposed patch Here is a possible implementation of the feature. Please let me know what you think. One thing that stands out to me as maybe being an issue is the fact that the new option is position dependent - it only affects filenames that come after it on the command line. (Much like the -L option). So: ld foo.o --remap-inputs=foo.o=bar.o will not rename foo.o to bar.o, whereas: ld --remap-inputs=foo.o=bar.o foo.o will perform the renaming. One other thing: I wondered if we ought to accept the "@file" syntax in the --remap-inputs option, as a synonym for --remap-inputs-file. What do you think ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30237] strip fails on riscv with 'not enough room for program headers, stgnjAlO[.interp]: bad value'
https://sourceware.org/bugzilla/show_bug.cgi?id=30237 --- Comment #8 from Andreas Schwab --- llvm-strip is quite broken: it fails to update the RISCV_ATTRIBUTES segment when .riscv.attributes is removed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30513] nm-new hangs infinitly on a special test case.
https://sourceware.org/bugzilla/show_bug.cgi?id=30513 Alan Modra changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- This is a problem demangling the rust symbol _RYODGYODGpe__RYODGpe. Please report rust demangler bugs to https://gcc.gnu.org/bugzilla/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30499] reword "alignment ... is smaller than alignment ..." warning
https://sourceware.org/bugzilla/show_bug.cgi?id=30499 --- Comment #4 from Michael Matz --- (In reply to Nick Clifton from comment #3) > (In reply to Michael Matz from comment #2) > > Hmm, on reflection this proposed message might not actually be correct. > > Generally one can't just increase the alignment of random data symbols like > > here: they might be part of a larger object with known relative offsets, and > > changing the alignment of such data symbol will then break such knowledge. > > Can this happen ? > > More to the point, if a meta-object does contain sub-objects with their own > symbols, shouldn't the offsets of those sub-objects be computed by > calculating > the difference between the symbol's address and the meta-object's start > address. Rather than just by being pre-calculated to some fixed value ? Sometimes yes. But the more usual case is that the addresses are encoded as section-relative. Especially so if the symbols in question aren't global, but still just so happen to be related (by positioning) to the common symbol that is tried to be moved around. For instance, in this example: % cat test1.s .type com2_,@object .comm com2_,8,64 .quad com2_ .type com1_,@object .comm com1_,8,64 .quad com1_ .section .note.GNU-stack % cat test2.s .globl com2_ .data randomstuff: .quad 1 .align 32 .type com1_, @object .size com1_, 8 com1_: .quad 2 .align 32 .type com2_, @object .size com2_, 8 com2_: .quad 2 foobar: .quad 3 addroffoobar: .quad foobar - randomstuff .section .note.GNU-stack main.c and compile commands as above. Note how I now have two "problematic" common symbols, both constrained to be 64-aligned from test1.s, but actually only getting a 32-alignment in test2.s. Not also that the distance between com1_ and com2_ is basically fixated in test2.s because I encode a distance between sourrounding (non-global) symbols. So, as a whole this .data section from test2.s can move happily around, but of course nothing can be added right _into_ that blob representing test2.o:.data. To wit: % cc ... ld: warning: alignment 32 of symbol `com2_' in test2.o is smaller than 64 in test1.o Note how it complains only about one, not both, symbols. And further: % readelf -sW a.out ... 15: 00404020 0 NOTYPE LOCAL DEFAULT 23 randomstuff ... 17: 00404068 0 NOTYPE LOCAL DEFAULT 23 foobar 18: 00404070 0 NOTYPE LOCAL DEFAULT 23 addroffoobar ... 28: 00404060 8 OBJECT GLOBAL DEFAULT 23 com2_ ... 43: 004040c0 8 OBJECT GLOBAL DEFAULT 25 com1_ % readelf -x .data a.out Hex dump of section '.data': 0x00404000 0x00404010 0x00404020 0100 0x00404030 0x00404040 0200 0x00404050 0x00404060 0200 0300 0x00404070 4800 H... So, it correctly left the distance between foobar and randomstuff at 0x48, both in symbol table and .data content. It achieved the 64-alignment of 'com1_' by letting the begin of test2.o:.data (corresponding also to the symbol 'randomstuff') be at 0x20 within a.out:.data. But that means that com2_ also had to move with it, to .data+0x60. That's _not_ 64-aligned. And especially it can't be made 64-aligned in any way. Either it would break the alignment of com1_ again, or it would change the distance between randomstuff and foobar, which wouldn't be able to rectified as no trace of that is left in the object files (and rightly so!). Curiously it only gave a warning message about com2_, which is the one where it couldn't do any alignment upgrade, but not about com1_ where it actually did change it. So, all in all, ultimately I think: a) the suggested wording of the warning is wrong, as not achievable in the general case b) the above example shows how the warning might even be regarded as error. Code that assumes 64-alignment for com1_ and com2_ (as requested by test1.o) _will_ break with the generated output and there's no way for the linker to magically make it work. In the interest of backward compatibility and in light of the existence of -fcommon for C, even though its default changed a couple years back, which makes mixture of common and data symbols be somewhat common, I'm not actually suggesting to make this an error, though. We could give the suggested wording of the warning in the very specific case where the target alignment is achievable. But the current code doesn't lend itself to that, at the place the warning is given it doesn't really know yet if that symbol can be over-aligned or not. (As shown above
[Bug binutils/30513] New: nm-new hangs infinitly on a special test case.
https://sourceware.org/bugzilla/show_bug.cgi?id=30513 Bug ID: 30513 Summary: nm-new hangs infinitly on a special test case. Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: swj22 at mails dot tsinghua.edu.cn Target Milestone: --- Created attachment 14917 --> https://sourceware.org/bugzilla/attachment.cgi?id=14917=edit the test case ## Write in front , i use afl to fuzz binutils2.40-nm-new , and then find this bug. ## command : nm-new -C file this test case , may make nm-new hang for much time until the system kill it , i have test it in ubuntu20.04 (compiler gcc 7.50 and gcc 9.4). it seems like a infinite loop , i use gdb to debug it , it behaves like infinite loop/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30499] reword "alignment ... is smaller than alignment ..." warning
https://sourceware.org/bugzilla/show_bug.cgi?id=30499 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- (In reply to Michael Matz from comment #2) > Hmm, on reflection this proposed message might not actually be correct. > Generally one can't just increase the alignment of random data symbols like > here: they might be part of a larger object with known relative offsets, and > changing the alignment of such data symbol will then break such knowledge. Can this happen ? More to the point, if a meta-object does contain sub-objects with their own symbols, shouldn't the offsets of those sub-objects be computed by calculating the difference between the symbol's address and the meta-object's start address. Rather than just by being pre-calculated to some fixed value ? If it is possible however then maybe the message should be: warning: alignment 32 of symbol `com2_' in test2.o changed to 64 to match test1.o warning: beware: this might break code that relies upon the alignment being 32. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30512] New: objdump 2.40 for risc-v doesn't have "addi" instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=30512 Bug ID: 30512 Summary: objdump 2.40 for risc-v doesn't have "addi" instruction Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: amitch1999 at gmail dot com Target Milestone: --- Created attachment 14916 --> https://sourceware.org/bugzilla/attachment.cgi?id=14916=edit binutils 2.39 vs 2.40 of the same ELF I have noticed the objdump for risc-v calls the "addi" instruction "add", and doesn't generates the "addi" instruction at all. I looked at the op code at it matches the "addi" instruction but in the dump it's named "add", and also the third argument is a number and not a register. Same for shift instructions. In binutils 2.39 it doesn't seem to happen. Might not be a bug, since it's pretty clear the the third argument is an immediate, but I think these two different instructions should have different names in the dump as well. -- You are receiving this mail because: You are on the CC list for the bug.
