Issue 31168 in oss-fuzz: binutils:fuzz_readelf: Timeout in fuzz_readelf
Updates: Labels: Deadline-Approaching Comment #5 on issue 31168 by sheriffbot: binutils:fuzz_readelf: Timeout in fuzz_readelf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31168#c5 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 libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #17 from Toolybird --- Just wanted to mention that while this libctf bug is still present, gcc-11 has been released which now ships a libiberty that includes bsearch_r() This means that building binutils with: 1. --enable-shared 2. --prefix=/usr 3. a system installed copy of libiberty.a (from gcc-11) results in functional binaries again. This is despite the fact that libctf is still (re)linking against the wrong libiberty.a -L/build/binutils/pkg/binutils/usr/lib -L/usr/lib <--- problem is here -lbfd -L/build/binutils/src/binutils-build/bfd/../libiberty/pic -L/build/binutils/src/binutils-build/libctf/../libiberty/pic -liberty -- You are receiving this mail because: You are on the CC list for the bug.
Issue 31427 in oss-fuzz: binutils:fuzz_readelf: Direct-leak with empty stacktrace
Updates: Labels: -restrict-view-commit Comment #4 on issue 31427 by sheriffbot: binutils:fuzz_readelf: Direct-leak with empty stacktrace https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31427#c4 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 gold/27869] gold lto link corrupt with segmentation fault [signal 11]
https://sourceware.org/bugzilla/show_bug.cgi?id=27869 --- Comment #1 from Cary Coutant --- Based on that stack trace, you appear to be linking an output file that has more than 64K sections in it. Obviously, gold should not be crashing when that happens, but what on earth are you linking that has so many output sections? That just shouldn't happen in any practical application. Solving that may work around this bug. Please add "-v -Wl,--debug=plugin" options, and send me the verbose gcc output and a tar file of the resulting debug directory. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27871] New: ld: Add -Bsymbolic-global-functions variant which only applies to STB_GLOBAL STT_FUNC
https://sourceware.org/bugzilla/show_bug.cgi?id=27871
Bug ID: 27871
Summary: ld: Add -Bsymbolic-global-functions variant which only
applies to STB_GLOBAL STT_FUNC
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
As a poor man's direct binding feature, -Bsymbolic-functions is incompatible
with two things:
(1) canonical PLT entries with -fno-pic code. This should be fixed on GCC's
side https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
(2) some vague linkage function definitions. See below
cat > ./a.cc < ./a.sh < ./b.cc <
inline void f() {}
void *g();
int main() {
printf("exe: %p\n", (void *));
printf("DSO: %p\n", g());
}
eof
On Mach-O, such symbols are placed into __LINKEDIT,__weak_binding so that dyld
can coalesce the definitions across dylibs.
For ELF, we can introduce -Bsymbolic-global-functions to exclude STB_WEAK
function definitions, avoiding the pointer equality issue.
For more context, see
https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#the-last-alliance-of-elf-and-men
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/27869] New: gold lto link corrupt with segmentation fault [signal 11]
https://sourceware.org/bugzilla/show_bug.cgi?id=27869 Bug ID: 27869 Summary: gold lto link corrupt with segmentation fault [signal 11] Product: binutils Version: 2.36.1 Status: UNCONFIRMED Severity: critical Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: chen.yunxing at me dot com CC: ian at airs dot com Target Milestone: --- I use gold with gcc 9.3 do lto link; and int lto-trans phase; failed with message: collect2: fatal error: ld terminated with signal 11 [segmentation fault] GCC: Using built-in specs. COLLECT_GCC=/usr/local/gcc-9.3.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-9.3.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-9.3.0/configure --disable-multilib --enable-languages=c,c++ --enable-checking=release --prefix=/home/admin/145_20200908214936062_162609878_code/rpm_workspace/rpm/.rpm_create/BUILD//usr/local/gcc-9.3.0 Thread model: posix gcc version 9.3.0 (GCC) the core information: [New LWP 47177] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/local/bin/ld.gold -plugin /usr/local/gcc-9.3.0/bin/../libexec/gcc/x86_64-p'. Program terminated with signal 11, Segmentation fault. #0 0x00625d83 in std::vector, std::allocator > >::emplace_back >(std::pair&&) (this=this@entry=0x38) at /usr/include/c++/9/bits/vector.tcc:109 109 vector<_Tp, _Alloc>:: Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.alios7.x86_64 libgcc-9.2.1-3.2.alios7.x86_64 libstdc++-9.2.1-3.2.alios7.x86_64 ob-gcc93-9.3.0-2020090910.alios7.x86_64 (gdb) bt #0 0x00625d83 in std::vector, std::allocator > >::emplace_back >(std::pair&&) (this=this@entry=0x38) at /usr/include/c++/9/bits/vector.tcc:109 #1 0x00711b9d in push_back (__x=, this=0x38) at /usr/include/c++/9/bits/stl_vector.h:1200 #2 add (shndx=, symndx=, this=0x0) at output.h:2939 #3 gold::Symbol_table::sized_write_globals<64, false> (this=0x7fff256bfd40, sympool=0x7fff256c00a0, dynpool=0x7fff256c0130, symtab_xindex=0xf980e990, dynsym_xindex=0x0, of=) at symtab.cc:3196 #4 0x00724aa0 in gold::Workqueue::find_and_run_task(int) () at token.h:290 #5 0x00724cca in gold::Workqueue::process (this=this@entry=0x7fff256bf9e0, thread_number=thread_number@entry=0) at workqueue.cc:495 #6 0x00413e67 in main () at main.cc:252 #7 0x7fd26cbeb445 in __libc_start_main () from /lib64/libc.so.6 #8 0x00415331 in _start () at errors.h:97 (gdb) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27871] ld: Add -Bsymbolic-global-functions which only applies to STB_GLOBAL STT_FUNC
https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Fangrui Song changed: What|Removed |Added Summary|ld: Add |ld: Add |-Bsymbolic-global-functions |-Bsymbolic-global-functions |variant which only applies |which only applies to |to STB_GLOBAL STT_FUNC |STB_GLOBAL STT_FUNC -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 Eli Zaretskii changed: What|Removed |Added CC||eliz at gnu dot org --- Comment #12 from Eli Zaretskii --- (In reply to cvs-com...@gcc.gnu.org from comment #11) > The master branch has been updated by Nick Clifton : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=749c700282097cf679ff019a9674d7c762f48619 > > commit 749c700282097cf679ff019a9674d7c762f48619 > Author: Thomas Wolff > Date: Mon May 10 11:28:15 2021 +0100 > > Restore old behaviour of windres so that options containing spaces are > not enclosed in double quotes. > > PR 4356 > PR 26865 > PR 27594 > * windres.c (quot): Revert previous delta. Do not use double > quotes when spaces are detected in options. > * doc/binutils.texi (windres): Remove suggestion that the > --preprocessor option can take arguments. So, given the discussion in PR 27594, are there any objections to reverting the `quot` part of commit 749c700, thus reinstating the changes in commit cc3edc5? If there are no objections, I'd like to go back to the correct quoting in `quot` on Windows. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/11] [x86] wrong code generated for "call DWORD PTR address" (-masm-intel)
https://sourceware.org/bugzilla/show_bug.cgi?id=11 --- Comment #3 from web_hero --- i use -ffunction-sections maybe this cause too many sections？ this opt option was used to reorder function in link stage i will post the info later ：） 发自我的iPhone > 在 2021年5月16日，上午3:53，ccoutant at gmail dot com > 写道： > > https://sourceware.org/bugzilla/show_bug.cgi?id=27869 > > --- Comment #1 from Cary Coutant --- > Based on that stack trace, you appear to be linking an output file that has > more than 64K sections in it. Obviously, gold should not be crashing when that > happens, but what on earth are you linking that has so many output sections? > That just shouldn't happen in any practical application. Solving that may work > around this bug. > > Please add "-v -Wl,--debug=plugin" options, and send me the verbose gcc output > and a tar file of the resulting debug directory. > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are on the CC list for the bug.
