[Bug binutils/26578] A memory leak in parse_gnu_debugaltlink
https://sourceware.org/bugzilla/show_bug.cgi?id=26578 --- 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=dfbee68088e822453fdc82f6b8a3a5bc468944b1 commit dfbee68088e822453fdc82f6b8a3a5bc468944b1 Author: Alan Modra Date: Wed Sep 9 16:38:36 2020 +0930 PR26578, memory leak in parse_gnu_debugaltlink The associated check function doesn't do anything with its "data" param, so nothing to adjust there. PR 26578 * dwarf.c (parse_gnu_debugaltlink): Don't alloc build_id_data. (load_separate_debug_files): Use a stack var for build_id_data. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26580] Size and alignment from as-needed shared library bss symbols affect commons
https://sourceware.org/bugzilla/show_bug.cgi?id=26580 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.36 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26578] A memory leak in parse_gnu_debugaltlink
https://sourceware.org/bugzilla/show_bug.cgi?id=26578 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |2.36 Status|ASSIGNED|RESOLVED --- Comment #2 from Alan Modra --- Patch applied -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26580] Size and alignment from as-needed shared library bss symbols affect commons
https://sourceware.org/bugzilla/show_bug.cgi?id=26580 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- Hi Alan, I am seeing new linker testsuite failures for the pr26580-2 test for the following targets: mips-elf extra regexps in ld/testsuite/ld-elf/pr26580-2.sd starting with "^.* 8 OBJECT GLOBAL DEFAULT .* one$" mn10300-elf ./ld-new: tmpdir/pr26580-2: error: PHDR segment not covered by LOAD segment score-elf ./ld-new: tmpdir/pr26580-2: error: PHDR segment not covered by LOAD segment Are these expected, or do we need to investigate further ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26589] ld segfaulting building uClibc-ng 1.0.35 for crisv32-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=26589 --- Comment #3 from wbx at openadk dot org --- Created attachment 12828 --> https://sourceware.org/bugzilla/attachment.cgi?id=12828&action=edit gcc -v -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26580] Size and alignment from as-needed shared library bss symbols affect commons
https://sourceware.org/bugzilla/show_bug.cgi?id=26580 --- Comment #4 from Alan Modra --- bfin-elf ./ld-new: the bfin target does not currently support the generation of copy relocations and other mips targets too. I saw all of these myself before committing the test, and decided they were sufficently unusual that I shouldn't just hide them with an xfail. At least not until investigating further. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26590] New: --as-needed doesn't work correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=26590 Bug ID: 26590 Summary: --as-needed doesn't work correctly Product: binutils Version: 2.36 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: amodra at gmail dot com Target Milestone: --- Created attachment 12829 --> https://sourceware.org/bugzilla/attachment.cgi?id=12829&action=edit A testcase [hjl@gnu-cfl-2 pr26530a]$ make gcc -B./ -O2 -g -c -o lto-18a.o lto-18a.c gcc -B./ -O2 -g -c -o lto-18d.o lto-18d.c gcc -B./ -O2 -g -fPIC -c -o lto-18b.o lto-18b.c ./ld -shared -o liblto-18b.so lto-18b.o gcc -B./ -O2 -g -fPIC -c -o lto-18c.o lto-18c.c ./ld -shared -o liblto-18c.so lto-18c.o gcc -B./ -Wl,--as-needed -o x lto-18a.o lto-18d.o liblto-18b.so liblto-18c.so -Wl,-R,. ./ld: liblto-18c.so: undefined reference to `f1' collect2: error: ld returned 1 exit status make: *** [Makefile:23: x] Error 1 [hjl@gnu-cfl-2 pr26530a]$ gcc -B./ -Wl,--as-needed -o x lto-18a.o lto-18d.o liblto-18b.so liblto-18c.so -Wl,-R,. -fuse-ld=gold [hjl@gnu-cfl-2 pr26530a]$ ./x 1 [hjl@gnu-cfl-2 pr26530a]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26590] --as-needed doesn't work correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=26590 --- Comment #1 from H.J. Lu --- Both gold and lld generate output. But [hjl@gnu-cfl-2 pr26530a]$ ./x 1 [hjl@gnu-cfl-2 pr26530a]$ LD_BIND_NOW=1 ./x ./x: symbol lookup error: ./liblto-18c.so: undefined symbol: f1 [hjl@gnu-cfl-2 pr26530a]$ I think the inputs are invalid and I prefer the current ld behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26590] --as-needed doesn't work correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=26590 --- Comment #2 from Alan Modra --- Your testcase demonstrates --as-needed working as designed. This is not a bug in ld.bfd and the fact that gold does not diagnose an undefined symbol does not mean much. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26391] Question regarding duplicate symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26391 --- Comment #4 from Kristen Carlson Accardi --- This feature was well received by the livepatch maintainers. It not only solves my individual problem, but also would allow them to more precisely locate duplicate symbols in general for patching. I'd like to request that this feature be implemented in a future release. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26391] Question regarding duplicate symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26391 --- Comment #5 from Kristen Carlson Accardi --- https://lore.kernel.org/live-patching/4dc070f53f4f96b47dba4e4e51bb65d75f2071bb.ca...@linux.intel.com/T/#mb29f61d93a1f0307212053c90ab86cb9fe5a64ee -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26391] Question regarding duplicate symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26391 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.36 URL||https://sourceware.org/pipe ||rmail/binutils/2020-Septemb ||er/113271.html --- Comment #6 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2020-September/113271.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26169] --dependency-file generates dependencies on unnecessary shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=26169 Roland McGrath changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Roland McGrath --- This is working as intended. 64/libbar.so is examined by the link and its contents are relevant to linking behavior. If you e.g. change bar.c so it no longer defines bar, and run make, then it will correctly rebuild bar.o and 64/libbar.so and correctly repeat the link of libfoo.so, which will now fail. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26588] enable-reloc-section on .exe with no exported symbols causes segfault if requested to create implib
https://sourceware.org/bugzilla/show_bug.cgi?id=26588 --- Comment #1 from sourceware-bugzilla at jdrake dot com --- (In reply to sourceware-bugzilla from comment #0) > I'm not sure whether it would be better to call generate_edata in the no > exports but enable reloc section case, or my proposed patch (attached) It seems that with --disable-reloc-section ld simply does not create the requested implib, so I believe my proposed patch would solve this regression. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26595] New: objdump/readelf debuginfod client not invoked for altdebug dwz file
https://sourceware.org/bugzilla/show_bug.cgi?id=26595 Bug ID: 26595 Summary: objdump/readelf debuginfod client not invoked for altdebug dwz file Product: binutils Version: 2.34 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: amerey at redhat dot com, woodard at redhat dot com Target Milestone: --- The debuginfod client code in objdump is appropriately invoked in --dwarf=follow-links mode, but it seems only for the main detached .debug file, but not its dependent .dwz file. To reproduce on f32: % export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/ % rm -rf ~/.cache/debuginfod_client % objdump --dwarf=follow-links -W /lib64/libboost_system.so.1.69.0 [observe incomplete data, observe reference to dwz buildid] % ls ~/.cache/debuginfod_client [observe only main boost_system .debug file, not dwz one] Same behaviour with readelf: % readelf --debug-dump=follow-links -w /lib64/libboost_system.so.1.69.0 -- You are receiving this mail because: You are on the CC list for the bug.
