[Bug ld/26314] Linking LTO objects with conflicting symbol definitions from static and shared libraries fails
https://sourceware.org/bugzilla/show_bug.cgi?id=26314 H.J. Lu changed: What|Removed |Added Attachment #12732|0 |1 is obsolete|| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26314] Linking LTO objects with conflicting symbol definitions from static and shared libraries fails
https://sourceware.org/bugzilla/show_bug.cgi?id=26314 H.J. Lu changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96385 URL||https://sourceware.org/pipe ||rmail/binutils/2020-July/11 ||2629.html --- Comment #2 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2020-July/112629.html -- You are receiving this mail because: You are on the CC list for the bug.
Issue 23778 in oss-fuzz: binutils:fuzz_bfd: Use-of-uninitialized-value in _bfd_pei_slurp_codeview_record
Updates: Labels: -restrict-view-commit Comment #3 on issue 23778 by sheriffbot: binutils:fuzz_bfd: Use-of-uninitialized-value in _bfd_pei_slurp_codeview_record https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23778#c3 This bug has been fixed for 30 days. 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 ld/26314] Linking LTO objects with conflicting symbol definitions from static and shared libraries fails
https://sourceware.org/bugzilla/show_bug.cgi?id=26314 H.J. Lu changed: What|Removed |Added Assignee|unassigned at sourceware dot org |hjl.tools at gmail dot com --- Comment #1 from H.J. Lu --- Created attachment 12732 --> https://sourceware.org/bugzilla/attachment.cgi?id=12732&action=edit A patch Please try this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 Florian Weimer changed: What|Removed |Added CC||fweimer at redhat dot com --- Comment #5 from Florian Weimer --- There are also PLT patching tools which would benefit from accurate entry sizes. (ltrace is an example, I believe.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 --- Comment #4 from Jakub Jelinek --- The gABI says: sh_entsize Some sections hold a table of fixed-size entries, such as a symbol table. For such a section, this member gives the size in bytes of each entry. The member contains 0 if the section does not hold a table of fixed-size entries. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 --- Comment #3 from Mark Wielaard --- (In reply to Szabolcs Nagy from comment #2) > i don't know about sh_entsize, i will have to check what it should be. In general sh_size modulo sh_entsize needs to be zero (if sh_entsize isn't zero itself). For non-zero sh_entsize sections, elfutils libelf will flag a section as corrupt if the sh_size % sh_entsize != 0. In this case, given that you have entries of variable size, I believe sh_entsize should be zero. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 Szabolcs Nagy changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #2 from Szabolcs Nagy --- the lack of PAC in PLT is deliberate: building with pac-ret does not enable pac-plt and glibc has no support for pac-plt anyway (ld.so would have to store signed addresses in PLTGOT entries) the PAC note is not very useful/obvious: it's documented to mark objects where pac-ret was in use throughout the code. (the dynamic linker does not have to do anything with it, it just allows tracking when something is not PAC protected). normal plt entry size is 16bytes, but the first plt entry size is always 32bytes. with DT_AARCH64_BTI_PLT the plt entry size is 24bytes, and the first plt entry size is 32bytes. i don't know about sh_entsize, i will have to check what it should be. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/20805] gcc's ThreadSanitizer broken by gold
https://sourceware.org/bugzilla/show_bug.cgi?id=20805 Blair Sansford changed: What|Removed |Added CC||tedguinan0982 at gmail dot com --- Comment #13 from Blair Sansford --- ld.bfd doesn't convert LD to LE. https://airgunmaniac.com/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 Jakub Jelinek changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #1 from Jakub Jelinek --- Non-uniform .plt sizes aren't necessarily a problem, but in that case sh_entsize needs to be changed, either to 0, 1, 4 or perhaps 8, but from the description 0 is probably the best choice. E.g. powerpc 32-bit is using sh_entsize of 0 for .plt too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26314] New: Linking LTO objects with conflicting symbol definitions from static and shared libraries fails
https://sourceware.org/bugzilla/show_bug.cgi?id=26314
Bug ID: 26314
Summary: Linking LTO objects with conflicting symbol
definitions from static and shared libraries fails
Product: binutils
Version: 2.35
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nickc at redhat dot com
Target Milestone: ---
In simplest terms, if we use LTO to build binutils the resultant binaries will
fault all over the place. If you look at it in the debugger we'll have jumped
to 0x0 via an indirect jump out of the PLT. The problem is the GOT entries are
zero'd out.
It looks like the preconditions are:
First, we need to have a DSO which provides a symbol definition (libbfd).
Second, we need to have an executable which links against that DSO (ar). The
components of that executable are LTO objects and in one or more of those LTO'd
objects there must be another definition of the symbol in question (-liberty
and
libiberty.a referenced on the command line to link ar).
The when linking the executable the linker has to merge the two definitions.
In
general we'll prefer the version from the executable over the version from the
DSO.
However, in the case of an LTO link, the symbol's input section is marked as
SEC_EXCLUDE for the main executable (that seems to be an artifact of LTO and
the
section flags it uses). In that scenario the output section will be reset to
the ABS section. The net result is we create a dynamic symbol with an absolute
type.
When the dynamic linker performs its symbol resolution that absolute dynamic
symbol will take precedence over the symbol in the DSO and the dynamic linker
will slam a new value into the GOT entry for the symbol.
This is fairly abstract, so here is a reproducer in the form of binutils
itself that you can examine in a debugger. It uses the Fedora rawhide (f33)
binutils sources:
1. fedpkg clone binutils
2. sed -i -e 's/%define _lto_cflags/#define _lto_cflags/' binutils.spec
[This step disables a workaround currently in the binutils.spec.
The workaround disables building the binutils with LTO enabled].
3. fedpkg srpm
4. fedpkg mock-config > my.cfg
5. mock -r my.cfg --without=testsuite *.src.rpm
6. mock --uniqueext=xxx --dnf -r my.cfg shell
7. nm --dynamic /builddir/build/BUILD/binutils-2.35/binutils/.libs/ar
This will show lots of entries, including:
A lrealpath
Attempts to run the ar binary will fail, as will all the other newly
built binutils tools.
[I am attempting to create a simpler, stand alone reproducer for this
problem. I will add an update to this PR when/if I find one].
Jeff Law has come up with a hack which appears to fix the problem,
but we are not sure if it is the correct solution:
diff --git a/bfd/elflink.c b/bfd/elflink.c
index 998b72f228..2f06e835c1 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -1633,7 +1633,8 @@ _bfd_elf_merge_symbol (bfd *abfd,
&& newdef
&& (olddef
|| (h->root.type == bfd_link_hash_common
- && (newweak || newfunc
+ && (newweak || newfunc)))
+ && (oldsec->flags & SEC_EXCLUDE) == 0)
{
*override = TRUE;
newdef = FALSE;
THe effect here is the symbol will be resolved via the libbfd.so DSO. That
doesn't seem entirely correct since we have a definition of lrealpath in
libiberty, which is referenced twice on the link line.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 Peter Robinson changed: What|Removed |Added CC||pbrobinson at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] New: ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 Bug ID: 26312 Summary: ld produces broken PLT on aarch64 with BTI+PAC Product: binutils Version: 2.35 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: fweimer at redhat dot com Target Milestone: --- Target: aarch64 Building glibc 2.32 on Fedora rawhide with GCC 10.2, -mbranch-protection=standard, and binutils 2.35 results in a libc.so.6 which lacks PAC support, possibly due to missing PAC in libgcc.a for the outline atomics. (We build with -moutline-atomics as well.) This in itself should not be a problem. However, catgets/gencat is mislinked. The PLT is corrupted because its entry size is not constant (32 bytes for the first entry, 24 bytes for subsequent entryes, section table says 24 bytes): Disassembly of section .plt: 00401140 <.plt>: 401140: d503245fbti c 401144: a9bf7bf0stp x16, x30, [sp, #-16]! 401148: d0f0adrpx16, 41f000 <__FRAME_END__+0x1abd4> 40114c: f9474a11ldr x17, [x16, #3728] 401150: 913a4210add x16, x16, #0xe90 401154: d61f0220br x17 401158: d503201fnop 40115c: d503201fnop 00401160 : 401160: d503245fbti c 401164: d0f0adrpx16, 41f000 <__FRAME_END__+0x1abd4> 401168: f9474e11ldr x17, [x16, #3736] 40116c: 913a6210add x16, x16, #0xe98 401170: d61f0220br x17 401174: d503201fnop 00401178 : 401178: d503245fbti c 40117c: d0f0adrpx16, 41f000 <__FRAME_END__+0x1abd4> 401180: f9475211ldr x17, [x16, #3744] 401184: 913a8210add x16, x16, #0xea0 401188: d61f0220br x17 40118c: d503201fnop I mentioned the lack of PAC earlier because ld seems to be confused about the PAC status. It only sets DT_AARCH64_BTI_PLT: Dynamic section at offset 0xfc60 contains 29 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [ld-linux-aarch64.so.1] 0x000c (INIT) 0x401120 0x000d (FINI) 0x403868 0x0019 (INIT_ARRAY) 0x41fc40 0x001b (INIT_ARRAYSZ) 8 (bytes) 0x001a (FINI_ARRAY) 0x41fc48 0x001c (FINI_ARRAYSZ) 8 (bytes) 0x0004 (HASH) 0x400330 0x6ef5 (GNU_HASH) 0x400498 0x0005 (STRTAB) 0x400990 0x0006 (SYMTAB) 0x4004e0 0x000a (STRSZ) 575 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0015 (DEBUG) 0x0 0x0003 (PLTGOT) 0x41fe80 0x0002 (PLTRELSZ) 1008 (bytes) 0x0014 (PLTREL) RELA 0x0017 (JMPREL) 0x400d30 0x0007 (RELA) 0x400c88 0x0008 (RELASZ) 168 (bytes) 0x0009 (RELAENT)24 (bytes) 0x7001 (AARCH64_BTI_PLT) 0x0018 (BIND_NOW) 0x6ffb (FLAGS_1)Flags: NOW 0x6ffe (VERNEED)0x400c38 0x6fff (VERNEEDNUM) 2 0x6ff0 (VERSYM) 0x400bd0 0x (NULL) 0x0 But the note says it has both: Displaying notes found in: .note.gnu.property OwnerData sizeDescription GNU 0x0010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI, PAC -- You are receiving this mail because: You are on the CC list for the bug.
