[Bug gold/28871] gold: --no-define-common is incompatible with GNU ld
https://sourceware.org/bugzilla/show_bug.cgi?id=28871 --- Comment #3 from Fangrui Song --- The semantics are different. % ld.bfd -r --no-define-common a.o -o a.ro && readelf -Ws a.ro ld.bfd: --no-define-common may not be used without -shared % ld.bfd -shared --no-define-common a.o -o a.so && readelf -Ws a.so Symbol table '.dynsym' contains 2 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 OBJECT GLOBAL DEFAULT UND x Symbol table '.symtab' contains 3 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 2f40 0 OBJECT LOCAL DEFAULT7 _DYNAMIC 2: 0 OBJECT GLOBAL DEFAULT UND x See that x is undefined in GNU ld. In gold, --[no-]define-common controls whether st_shndx is SHN_COMMON or not (allocated space or not). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/28871] gold: --no-define-common is incompatible with GNU ld
https://sourceware.org/bugzilla/show_bug.cgi?id=28871 --- Comment #2 from Cary Coutant --- I do not see how gold's --no-define-common is incompatible with ld's. According to the ld manual, and from looking at the original ld patch, they seem to do exactly the same thing, which is in fact the opposite of -d. If your complaint is that --define-common is accepted by gold but not by ld, I do not see that as sufficient grounds to remove it from gold. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 40823 in oss-fuzz: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 40823 by sheriffbot: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40823#c4 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.
Issue 40892 in oss-fuzz: binutils:fuzz_addr2line: Undefined-shift in place_sections
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 40892 by sheriffbot: binutils:fuzz_addr2line: Undefined-shift in place_sections https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40892#c4 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.
Issue 41052 in oss-fuzz: binutils:fuzz_as: Null-dereference READ in section_symbol
Updates: Labels: Deadline-Approaching Comment #2 on issue 41052 by sheriffbot: binutils:fuzz_as: Null-dereference READ in section_symbol https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41052#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.
Issue 41034 in oss-fuzz: binutils:fuzz_bfd_ext: Direct-leak in bfd_zmalloc
Updates: Labels: Deadline-Approaching Comment #2 on issue 41034 by sheriffbot: binutils:fuzz_bfd_ext: Direct-leak in bfd_zmalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41034#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.
Re: Is this a bug?
Hi Zane, Hi. I am trying to compile binutils 2.37. But when the Makefile run > gcc.exe: fatal error: no input files What do I do? There is some suspicious quoting in the command line, starting with: "-DBINDIR=\\C:/test/normalGcc/bin\" (Note how the closing quote is escaped) And ending with: ../../binutils-2.37/bfd/archive.c" It looks to me like the command line defining one very long symbol called BINDIR which contains a lot more than just a path to a bin directory. I have no idea why this is happening though. Perhaps it is related to how you ran the configure script ? Cheers Nick
[Bug binutils/28862] heap-buffer-overflow in parse_stab_string
https://sourceware.org/bugzilla/show_bug.cgi?id=28862 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Target Milestone|--- |2.39 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28862] heap-buffer-overflow in parse_stab_string
https://sourceware.org/bugzilla/show_bug.cgi?id=28862 --- Comment #1 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=481153777e278b71e694fd2db6b897f7a9e3dcb8 commit 481153777e278b71e694fd2db6b897f7a9e3dcb8 Author: Alan Modra Date: Tue Feb 8 20:21:01 2022 +1030 PR28862, heap-buffer-overflow in parse_stab_string I have no info on the format of a "SUNPRO C++ Namespace" stab, so am relying on the previous code being correct in parsing these stabs. Just don't allow NULs anywhere in the stab. PR 28862 * stabs.c (parse_stab_string): Don't overrun buffer when parsing 'Y' stab. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/28871] New: gold: --no-define-common is incompatible with GNU ld
https://sourceware.org/bugzilla/show_bug.cgi?id=28871 Bug ID: 28871 Summary: gold: --no-define-common is incompatible with GNU ld Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: i at maskray dot me CC: ian at airs dot com Target Milestone: --- In 2001-09, [optionally postpone assignment of Common](https://sourceware.org/pipermail/binutils/2001-September/014015.html) added --no-define-common to be used with -shared. --define-common is not implemented. Here is my understanding: glibc around 2.1.3 used to have a ld.so bug that the ELF interposition might not work. Using --no-define-common with shared objects can make COMMON symbols undefined and circumvent the bug. gold confuses --define-common with -d/FORCE_COMMON_ALLOCATION (commit 0dfbdef4c43cfe12bb3e2505ebe5acc651a35c98) and implements --define-common with -d semantics. Its --no-define-common is incompatible with GNU ld. I suggest that gold removes --[no-]define-common. Debian Code Search says no project uses this option. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/28871] gold: --no-define-common is incompatible with GNU ld
https://sourceware.org/bugzilla/show_bug.cgi?id=28871 --- Comment #1 from Fangrui Song --- https://sourceware.org/pipermail/binutils/2022-February/119689.html [PATCH] gold: Remove GNU ld incompatible --[no-]define-common [BZ #28871] -- You are receiving this mail because: You are on the CC list for the bug.
