[Bug ld/27259] ld: Support SHF_LINK_ORDER self-link
https://sourceware.org/bugzilla/show_bug.cgi?id=27259 --- Comment #9 from Fangrui Song --- (In reply to Alan Modra from comment #7) > How exactly is the proposed SHF_LINK_ORDER trick supposed to work? A > reference to start_foo/stop_foo symbols from a kept section currently marks > all input sections named foo as kept. Are you suggesting that any section > named foo that is SHF_LINK_ORDER with a self-link should not be marked? But > those foo that do not have a self-link should be marked? > > Has there been any comment about this idea from the gABI group? Started https://groups.google.com/g/generic-abi/c/LxmRJRBBbHk "__start_/__stop_ symbols and GC". No response yet. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27355] New: SEGFAULT in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27355 Bug ID: 27355 Summary: SEGFAULT in dwarf2dbg.c Product: binutils Version: 2.37 (HEAD) Status: UNCONFIRMED Severity: critical Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sirus.shahini at gmail dot com Target Milestone: --- Created attachment 13203 --> https://sourceware.org/bugzilla/attachment.cgi?id=13203&action=edit Sample input Hello, Our fuzzer detected another pointer corruption in "allocate_filename_to_slot()" function. A sample crashing input with null address dereference has been attached. Assemble with 'as'. No specific option is required for reproducing the bug. Our investigation suggests this is a critical bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27349] ar breaks symlinks
https://sourceware.org/bugzilla/show_bug.cgi?id=27349 --- 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=51a25252814f8b6f88ff5999a091e47ca1dbdeb9 commit 51a25252814f8b6f88ff5999a091e47ca1dbdeb9 Author: Alan Modra Date: Fri Feb 5 22:33:08 2021 +1030 PR27349, ar breaks symlinks PR 27349 * rename.c (smart_rename): Test for existence and type of output file with lstat. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27349] ar breaks symlinks
https://sourceware.org/bugzilla/show_bug.cgi?id=27349 Alan Modra changed: What|Removed |Added Assignee|siddhesh at sourceware dot org |amodra at gmail dot com Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |2.37 --- Comment #2 from Alan Modra --- Fixed mainline. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27348] obsolete Xcustom support in riscv port
https://sourceware.org/bugzilla/show_bug.cgi?id=27348 Jim Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jim Wilson --- Mark as resolved/fixed as it is fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/26678] construction vtable defined in a discarded section
https://sourceware.org/bugzilla/show_bug.cgi?id=26678 Cary Coutant changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Cary Coutant --- This appears to be a bug in GCC, but the inline asm, being outside the ABI, could simply render this an unfortunate incompatibility between GCC and Clang. The problem is that the inline asm is making GCC think that ~A::A() can raise an exception, so it creates compensation code in D::D(), which requires a construction vtable for B-in-C, which gets added to the COMDAT group that also contains the vtable for C (_ZV1C). Here's the code GCC generates for D::D(), from a.o: 0002 <_ZN1DC1E1C>: 2: 48 83 ec 18 sub$0x18,%rsp 6: 48 8b 06mov(%rsi),%rax 9: 48 8b 40 e8 mov-0x18(%rax),%rax d: 8b 04 06mov(%rsi,%rax,1),%eax 10: 89 44 24 08 mov%eax,0x8(%rsp) 14: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 1b <_ZN1DC1E1C+0x19> 17: R_X86_64_REX_GOTPCRELX _ZTV1C-0x4 1b: 48 8d 40 18 lea0x18(%rax),%rax 1f: 48 89 04 24 mov%rax,(%rsp) 23: 48 89 e7mov%rsp,%rdi 26: e8 00 00 00 00 callq 2b <_ZN1DC1E1C+0x29> 27: R_X86_64_PLT32 _Z1f1C-0x4 2b: eb 17 jmp44 <_ZN1DC1E1C+0x42> 2d: 48 89 c7mov%rax,%rdi 30: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# 37 <_ZN1DC1E1C+0x35> 33: R_X86_64_PC32 _ZTC1C0_1B+0x14 37: 48 89 04 24 mov%rax,(%rsp) 3b: 89 44 24 08 mov%eax,0x8(%rsp) 3f: e8 00 00 00 00 callq 44 <_ZN1DC1E1C+0x42> 40: R_X86_64_PLT32 _Unwind_Resume-0x4 44: 48 83 c4 18 add$0x18,%rsp 48: c3 retq The code from offset 0x2d through the callq at 0x3f is the compensation code generated if an exception happens during the call of f(c). Without that inline asm, GCC would have generated the same code as clang, with no compensation code and no construction vtable necessary. Compile with --no-exceptions, and the problem also goes away. I see the same problem whether compiling a.cpp at -O0, -O1, -O2, or -O3. At least GCC is consistent when compiling a.cpp and main.cpp, so it could be argued that this case simply isn't covered by the C++ ABI, and GCC and Clang are free to treat it differently. I made some trivial attempts to reproduce with something other than inline asm, but could not. As for why you're getting an error from gold, but not from bfd or lld, gold is reporting what could have been a real error, though in this particular case, since an exception could never have been thrown, the compensation code would never have executed. But when you link with bfd ld or lld, the lea instruction at 0x2d is left unrelocated, with no warning, and the program could conceivably crash in the case of an exception being thrown during the call to f(). -- You are receiving this mail because: You are on the CC list for the bug.
