[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile
https://sourceware.org/bugzilla/show_bug.cgi?id=32003 --- Comment #28 from Luca Boccassi --- As user and owner of the spec, I am fine with any of those options. A slight preference for a new command line (option A), as that means you don't need to worry about version matching - if the new flag is there, then you can pass encoded input, if it's not, then you know it only takes unencoded input. But not a strong preference. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile
https://sourceware.org/bugzilla/show_bug.cgi?id=32003 --- Comment #29 from Andreas K. Huettel --- > > Option A: Introduce a new --encoded-package-metadata parameter that takes > the encoded string. > > Option B: Extend --package-metadata to always decode the given string. As > previously discussed, package names and version should not contain percent > characters. So this change should not break backward compatibility. > What are you going to do once you run into command line length limits (which can be hidden in many places)? (How much mystery data are we really talking about here?) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile
https://sourceware.org/bugzilla/show_bug.cgi?id=32003 --- Comment #30 from H.J. Lu --- (In reply to Benjamin Drung from comment #27) > Option A: Introduce a new --encoded-package-metadata parameter that takes > the encoded string. This option isn't readable. > Option B: Extend --package-metadata to always decode the given string. As > previously discussed, package names and version should not contain percent > characters. So this change should not break backward compatibility. This is the readable option. > Which of those proposals do you want to see implemented? My initial > implementation is option 1A. We should have a readable option. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary
https://sourceware.org/bugzilla/show_bug.cgi?id=32067 --- Comment #4 from Sourceware Commits --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=602f5cf7e3a82229d75998a5f6eb13753f828bb3 commit 602f5cf7e3a82229d75998a5f6eb13753f828bb3 Author: H.J. Lu Date: Sat Aug 10 07:23:53 2024 -0700 ld: Add PR ld/32067 tests Add PR ld/32067 tests with the compiler driver since the -plugin option is needed to trigger this --oformat binary bug. PR ld/32067 * testsuite/ld-i386/i386.exp: Run PR ld/32067 test. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-i386/start.s: Add .note.GNU-stack section. * testsuite/ld-x86-64/pr32067.s: New file. Signed-off-by: H.J. Lu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/32071] New: undefined weak hidden function symbols resolves to garbage
https://sourceware.org/bugzilla/show_bug.cgi?id=32071 Bug ID: 32071 Summary: undefined weak hidden function symbols resolves to garbage Product: binutils Version: 2.43 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: ishitatsuyuki at gmail dot com CC: chris at smowton dot net, ian at airs dot com Target Milestone: --- When there is no definition for a weak undef STT_FUNC symbol, the function's address should resolve to absolute zero, not some random address. In Bug 15435 gold was changed to accept weak undefs with STV_HIDDEN, however when no definition is present it seems to resolve to some garbage address [1], instead of zero. This is easily reproducible with the sample from the same bug. --- extern void undefined () __attribute__((visibility("hidden"))) __attribute__((weak)); int main () { if (&undefined != 0) return 1; return 0; } --- $ gcc main.c -fuse-ld=bfd && ./a.out; echo $? 0 $ gcc main.c -fuse-ld=gold && ./a.out; echo $? 1 $ gcc main.c -fuse-ld=lld && ./a.out; echo $? 0 $ gcc main.c -fuse-ld=mold && ./a.out; echo $? 0 [1]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29986#note_2516917 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary
https://sourceware.org/bugzilla/show_bug.cgi?id=32067 --- Comment #5 from Sam James --- Thank you Alan and H.J.! I wasn't sure how to stop it getting there in the first place. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary
https://sourceware.org/bugzilla/show_bug.cgi?id=32067 --- Comment #6 from Alan Modra --- HJ, when looking at the loop setting non_ir_ref_regular, I noticed the test of info->strip in determining whether to look at debug sections' relocs. That seems wrong to me. Should you allow a debug reference to a symbol to potentially affect LTO output? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary
https://sourceware.org/bugzilla/show_bug.cgi?id=32067 --- Comment #7 from H.J. Lu --- (In reply to Alan Modra from comment #6) > HJ, when looking at the loop setting non_ir_ref_regular, I noticed the test > of info->strip in determining whether to look at debug sections' relocs. > That seems wrong to me. Should you allow a debug reference to a symbol to > potentially affect LTO output? When debug symbols are stripped and are only referenced in debug sections, they aren't needed for output. -- You are receiving this mail because: You are on the CC list for the bug.