[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Note with -flto it is difficult to argue about the order of "source" objects and library references with -l, say you'd have gcc t.c -lpthread t2.c -flto gcc can then, via -flto, happily produce only a single "real" ltrans object. Of course via the plugin it should get the original refs of t.c and t2.c in the correct order but my understanding is that BFD re-scans objects (because GCC is also prone to introduce new refs, for example to memcpy, libm functions or libgcc provided functions). But "placement" of the generated ltrans object on the linker command-line is not well-defined since the plugin merely provides LD with extra objects it should link. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #8 from Alan Modra --- (In reply to Michael Matz from comment #3) > % gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so bad4.c -L. -l2 -l1 > % readelf-dW good.so | grep lib > 0x0001 (NEEDED) Shared library: [lib2.so] > 0x0001 (NEEDED) Shared library: [lib1.so] I'd actually like to fix the above to *not* have DT_NEEDED lib2.so. The reason is that as-needed was supposed to be modeled on the way archive entries are treated, and if you were using static libraries you'd find the weak func1 in lib2.a would not be enough to cause lib2.o to be extracted.. Unfortunately I can't do that, libm.so.6 for instance is full of weak dynamic symbols. So for as-needed shared libraries we instead say the library is needed whenever a non-weak undefined reference is satisfied by the library regardless of whether the definition is strong or weak. I guess I need to do the same for plugins. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27459] segmentation fault in go32exe_check_format
https://sourceware.org/bugzilla/show_bug.cgi?id=27459 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Alan Modra --- Fixed for 2.37 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27459] segmentation fault in go32exe_check_format
https://sourceware.org/bugzilla/show_bug.cgi?id=27459 --- Comment #2 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=93af1b046b76380c1b06940c31581c30001d27de commit 93af1b046b76380c1b06940c31581c30001d27de Author: Alan Modra Date: Wed Feb 24 10:52:47 2021 +1030 PR27459, segmentation fault in go32exe_check_format PR 27459 * coff-stgo32.c (go32exe_check_format): Sanity check size of header to avoid a buffer overflow. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27459] segmentation fault in go32exe_check_format
https://sourceware.org/bugzilla/show_bug.cgi?id=27459 Alan Modra changed: What|Removed |Added Severity|critical|normal Last reconfirmed||2021-02-24 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |2.37 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Summary|Improper device name can|segmentation fault in |cause seg |go32exe_check_format |fault/crash/denial of | |service in png_handle_IHDR | Ever confirmed|0 |1 --- Comment #1 from Alan Modra --- The summary and backtrace doesn't correspond to the segmentation fault you found, but no matter, the poc attached is sufficient to show the bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/23691] [2.32 Regression] FAIL: gas/rx/gprel
https://sourceware.org/bugzilla/show_bug.cgi?id=23691 --- 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=55add51eef6b4f89d44e1a6753d4dd926cab70c7 commit 55add51eef6b4f89d44e1a6753d4dd926cab70c7 Author: Alan Modra Date: Tue Feb 23 21:54:25 2021 +1030 PR23691, gas .y files vs. automatic make dependencies A number of targets, bfin, rl78, rx, can show odd failures when bfd/reloc.c changes BFD_RELOC_* enum values, if recompiling over a build dir with existing objects. The problem is caused by bfin-parse.o and similar not being recompiled and so using stale BFD_RELOC_* values. This isn't fixed by making bfin-parse.c depend on bfd/reloc.c, which isn't necessary anyway. bfin-parse.o should have been recompiled due to bfd/bfd.h changing when extracted bfd/reloc.c BFD_RELOC_* values change, but that wasn't happening. The problem is that automake generates a makefile that loads gas/config/.deps/ dependency file for objects with corresponding sources mentioned in EXTRA_as_new_SOURCES. Unless we want to mess around generating explicit dependencies, I think that mean moving some object files to the build gas/config/. This patch does that, removing some hacks for m68k-parse.c that should no longer be necessary, and removes some rules that catered to old bison producing code that triggers compiler warnings. PR 23691 * Makefile.am (TARGET_CPU_CFILES): Split off config/xtensa-relax.c.. (TARGET_CPU_HFILES): ..and config/xtensa-relax.h.. (TARGET_EXTRA_FILES): ..to here. Add config/bfin-lex-wrapper.c, and use alongside TARGET_CPU_CFILES. (EXTRA_DIST): Update location of generated .c files. (config/m68k-parse.c): New rule replacing m68k-parse.c rule. (config/bfin-parse.c, config/rl78-parse.cm config/rx-parse.c), (config/bfin-lex.c, config/bfin-lex-wrapper.@OBJEXT@): Similarly. (itbl-lex-wrapper.@OBJEXT@): Simplify to just the needed dependencies. (itbl-parse.@OBJEXT@): Delete rule using NO_WERROR. (itbl-parse.c, itbl-parse.h): Tidy. * config/bfin-lex-wrapper.c: Include config/bfin-lex.c. * config/bfin-lex.l: Include config/bfin-parse.h. * configure.ac (extra_objects): Move object files corresponding to .y and .l files now in config/ to config/. * Makefile.in: Regenerate. * configure: Regenerate. * po/POTFILES.in: Regenerate. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27456] Link failure due to the use of lstat in rename.c on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=27456 --- Comment #7 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=cca8873dd5a6015d5557ea44bc1ea9c252435a29 commit cca8873dd5a6015d5557ea44bc1ea9c252435a29 Author: Alan Modra Date: Tue Feb 23 09:37:39 2021 +1030 PR27456, lstat in rename.c on MinGW PR 27456 * rename.c: Tidy throughout. (smart_rename): Always copy. Remove windows specific code. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27456] Link failure due to the use of lstat in rename.c on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=27456 --- Comment #8 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=c42c71a1527dd70417d3966dce7ba9edbcf4bdb4 commit c42c71a1527dd70417d3966dce7ba9edbcf4bdb4 Author: Alan Modra Date: Tue Feb 23 12:10:58 2021 +1030 Use make_tempname file descriptor in smart_rename This patch makes use of the temp file descriptor in smart_rename rather than reopening the file. I don't believe there is a security issue in reopening the file, but this way is one less directory operation. The patch also attempts to preserve S_ISUID and S_ISGID. PR 27456 * bucomm.h (smart_rename): Update prototype. * rename.c (smart_rename): Add fromfd and preserve_dates params. Pass fromfd and target_stat to simple_copy. Call set_times when preserve_dates. (simple_copy): Accept fromfd rather than from filename. Add target_stat param. Rewind fromfd rather than opening. Open "to" file without O_CREAT. Try to preserve S_ISUID and S_ISGID. * ar.c (write_archive): Rename ofd to tmpfd. Dup tmpfd before closing output temp file, and pass tmpfd to smart_rename. * arsup.c (temp_fd): Rename from real_fd. (ar_save): Dup temp_fd and pass to smart_rename. * objcopy.c (strip_main, copy_main): Likewise, and pass preserve_dates. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27456] Link failure due to the use of lstat in rename.c on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=27456 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #6 from Alan Modra --- Created attachment 13258 --> https://sourceware.org/bugzilla/attachment.cgi?id=13258=edit verbose log In my binutils.log from running make check under Ubuntu linux on x86_64, I see Executing on host: /home/alan/build/gas/all/binutils/objcopy --version (timeout = 300) spawn -ignore SIGHUP /home/alan/build/gas/all/binutils/objcopy --version GNU objcopy (GNU Binutils) 2.36.50.20210223 for the lines corresponding to comment #4. The attached file, terminal output from make RUNTESTFLAGS="objcopy.exp -v -v" check in the binutils subdir up to the point where the above executes might help you track down where things are going wrong on your system. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27451] ld: Provide a way to make C identifier name sections GCable under __start_/__stop_ references
https://sourceware.org/bugzilla/show_bug.cgi?id=27451 --- Comment #1 from Fangrui Song --- In LLD, I'll add -z start-stop-gc to let __start_/__stop_ not retain C identifier name sections (https://reviews.llvm.org/D96914). -z nostart-stop-gc can disable it. For SHF_LINK_ORDER or SHF_GROUP sections, __start_/__stop_ references do not retain them, regardless of -z start-stop-gc or -z nostart-stop-gc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-23 Status|UNCONFIRMED |NEW --- Comment #7 from H.J. Lu --- Please try users/hjl/pr26530/master branch: https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/master -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27456] Link failure due to the use of lstat in rename.c on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=27456 --- Comment #5 from Markus Böck --- That's less than optimal to say the least. Is it possible to tell it which ar to test? ar.exe exists in /binutils along the other files but instead of ar.exe it tries to invoke just ar. I tried setting AR to the absolute path to ar.exe but it still used ar. Running $AR -v works on the command line. Since I am in the WSL I can execute Windows executables without issues and I have run GCC tests like this before too, so I'd think it'd work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #6 from Michael Matz --- Probably just one more corner case (the last one!) ;-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #5 from Martin Liska --- The issue started with: commit b1a92c635c1ec10fd703302ce1fc4ab3a8515a04 Author: Alan Modra Date: Fri Oct 30 14:56:35 2020 +1030 PR26806, Suspected linker bug with LTO This patch reverts most of git commit 1e3b96fd6cf, so IR symbols are again not marked def_regular or ref_regular. That should be enough to stop IR symbols from becoming dynamic. To mark as-needed shared libraries referenced by IR symbols, use the referencing BFD rather than the ref flags. bfd/ PR 15146 PR 26314 PR 26530 PR 26806 * elflink.c (elf_link_add_object_symbols): Don't set def/ref flags for plugin syms. Do allow plugin syms to mark as-needed libs. ld/ PR 26806 * testsuite/ld-plugin/lto-19.h, * testsuite/ld-plugin/lto-19a.c, * testsuite/ld-plugin/lto-19b.c, * testsuite/ld-plugin/lto-19c.c: New test. * testsuite/ld-plugin/pr26806.c, * testsuite/ld-plugin/pr26806.d: New test. * testsuite/ld-plugin/lto.exp: Run them. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27294] Potentially exploitable Heap Overwrites in avr_elf32_load_records_from_section()
https://sourceware.org/bugzilla/show_bug.cgi?id=27294 --- Comment #3 from Dennis Roellke --- My bad, it's not off-by-one. record_count is a user controlled input field, s.t. a malicious user could set the record_count for x counts to y and force a heap overwrite in https://sourcegraph.com/github.com/bminor/binutils-gdb@a7e3d08a26edefa411269636d7dcae7dd2736659/-/blob/bfd/elf32-avr.c#L4089 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #4 from Michael Matz --- (I've now verified that it doesn't happen with older binutils (2.26 :) ) but does with 2.36, with otherwise same toolchain (some random gcc-9 compiler), so it's not any gcc component) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
Michael Matz changed:
What|Removed |Added
Assignee|ccoutant at gmail dot com |unassigned at
sourceware dot org
Component|gold|ld
--- Comment #3 from Michael Matz ---
So, like this:
% cat lib1.c
int func1(void) { return 1; }
int func2(void) { return 2; }
% cat lib2.c
int __attribute__((weak)) func1(void) { return 3; }
% cat bad4.c
extern int func1(void);
extern int func2(void);
int callthem(void)
{
return func1() + func2();
}
% gcc -fPIC -shared -o lib1.so lib1.c
% gcc -fPIC -shared -o lib2.so lib2.c
% gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so bad4.c -L. -l2 -l1
% readelf-dW good.so | grep lib
0x0001 (NEEDED) Shared library: [lib2.so]
0x0001 (NEEDED) Shared library: [lib1.so]
% gcc -fPIC -Wl,--as-needed -flto -shared -o bad.so bad4.c -L. -l2 -l1
% readelf -dW bad.so | grep lib
0x0001 (NEEDED) Shared library: [lib1.so]
(I'm resetting component to ld again, as I think the above shows the problem
clearly enough. It's still possible that it's the gcc LTO plugin at fault,
though)
--
You are receiving this mail because:
You are on the CC list for the bug.
