[Bug ld/28021] riscv: wrong double relaxation with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=28021 --- Comment #1 from Andreas Schwab --- I'd guess the other archs never see that issue since versioned aliases are a rare thing in the embedded world. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28021] riscv: wrong double relaxation with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=28021 Martin Liska changed: What|Removed |Added CC||mliska at suse dot cz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28021] New: riscv: wrong double relaxation with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=28021
Bug ID: 28021
Summary: riscv: wrong double relaxation with LTO
Product: binutils
Version: 2.37 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
This is related to the fix for PR22756, which turns out to be incomplete.
We have seen the problem with GCC11 and it needs LTO, which makes this a bit
involved to reproduce. See https://bugzilla.suse.com/show_bug.cgi?id=1187542
for how it came to be, but it contains unrelated things. Eventually I came up
with a single file testcase without compiler, but that involved a hex-edited
.o file. After much back and forth I came up with a two-file testcase that
only involves assembler, no compiler, and that I believe faithfully reflects
the error
mode. So, the files:
% cat relax-twice-1.s
.file ""
.option pic
.text
# this align is here so that the .text section starts at 0x1000,
# in order to make matching of testcase results easier
.align 12
.globl foobar_new
.weak foobar_new
.type foobar_new, @function
foobar_new:
jr ra
.size foobar_new, .-foobar_new
.symver foobar_new, foobar@@New
.section.note.GNU-stack,"",@progbits
% cat relax-twice-2.s
.file ""
.option pic
.text
.section.rodata.str1.8,"aMS",@progbits,1
.align 3
.LC0:
.string "%u"
.text
.align 1
.globl relaxme
.type relaxme, @function
relaxme:
addisp,sp,-32
addia2,sp,12
lla a1,.LC0
li a0,0
sd ra,24(sp)
callsscanf@plt
ld ra,24(sp)
addisp,sp,32
jr ra
.size relaxme, .-relaxme
.align 1
.globl foobar_new
.type foobar_new, @function
foobar_new:
li a0,1
ret
.size foobar_new, .-foobar_new
.symver foobar_new, foobar@@New
.align 1
.globl foobar_old
.type foobar_old, @function
foobar_old:
addisp,sp,-16
sd ra,8(sp)
callfoobar@plt
ld ra,8(sp)
sneza0,a0
addisp,sp,16
jr ra
.size foobar_old, .-foobar_old
.symver foobar_old, foobar@Old
.section.note.GNU-stack,"",@progbits
% cat relax-twice.ver
Old {
global:
foobar;
relaxme;
local:
*;
};
New {
global:
foobar;
} Old;
% ../as-new -o relax-twice-1.o relax-twice-1.s
% ../as-new -o relax-twice-2.o relax-twice-2.s
% ../ld-new -o bla.so --relax -shared --version-script relax-twice.ver
relax-twice-1.o relax-twice-2.o
% nm bla.so
...
102c t foobar_new
1028 T foobar@@New
...
Note how these two symbols are supposed to point to the same address. (The
stunt with the weak variant of foobar_new and foobar@@New in relax-twice-1.s
is only there to prime the internal symbol table of ld in the same way as
it would have been with LTO and the linker plugin. The prevailing variants
are the ones from relax-twice-2.s)
The reason is the one already analyzed in PR22756: multiple entries in
sym_hashes[] pointing to the same symbol entry, such that the relaxation code
adjusts the same entry multiple times. That is the situation always created
by aliases, and the PR22756 patch fixes it for hidden aliases (created by
non-default symbol versions, i.e. foobar@BLA). Of course the same can happen
with non-hidden aliases, as above demonstrates.
A definitely working fix would be to always check for duplicates, but a
slowdown
for that can then only be avoided by extending the elf symbol hash structure
to contain an already-handled flag. The more immediate, but possibly also
still incomplete fix is simply:
--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -3993,7 +3993,7 @@ riscv_relax_delete_bytes (bfd *abfd, asection *sec,
bfd_vma addr, size_t count,
foo becomes an alias for foo@BAR, and hence they need the same
treatment. */
if (link_info->wrap_hash != NULL
- || sym_hash->versioned == versioned_hidden)
+ || sym_hash->versioned != unversioned)
{
struct elf_link_hash_entry **cur_sym_hashes;
I will note that the problem exists for all targets that implement relaxation
that can also delete bytes from sections (it seems to all have been copied
around for decades), at least MIPS and AVR seem somewhat relevant still, but
it's also m10[23]00, cr16, h8300, ip2k, m32c, m68hc11, msp430, rl78, rx and
v850. Only riscv goes to an effort to remidy the situation with symbol
aliases.
--
You are receiving this mail because:
You are
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 --- Comment #5 from Nick Alcock --- Mail sent out to binutils@ for review. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27659] BFD (GNU Binutils for Debian) 2.36.1 internal error, aborting at ../../bfd/elfcode.h:224 in bfd_elf32_swap_symbol_out
https://sourceware.org/bugzilla/show_bug.cgi?id=27659 --- Comment #8 from Gianfranco --- Created attachment 13516 --> https://sourceware.org/bugzilla/attachment.cgi?id=13516=edit log file Hello, looks like your patch was already into master branch, and then in Ubuntu development release "2.36.50.20210628" version. Sadly, I couldn't get anything more other than a "segmentation fault" but I could run it with "--verbose" flag, maybe it helps? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28019] New: ld killed by OOM killer linking QtWebengine 5.15
https://sourceware.org/bugzilla/show_bug.cgi?id=28019 Bug ID: 28019 Summary: ld killed by OOM killer linking QtWebengine 5.15 Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: be.0 at gmx dot com Target Milestone: --- Building Qt 5.15 with KDE's patches (https://invent.kde.org/qt/qt/qt5) on Fedora 34 with binutils-2.35.1-41.fc34.x86_64, linking QtWebEngineCore gets killed by the OOM killer. Build instructions are on the Qt wiki (https://wiki.qt.io/Building_Qt_5_from_Git). It needs this small patch to build with GCC 11: diff --git a/chromium/third_party/perfetto/src/trace_processor/containers/string_pool.h b/chromium/third_party/perfetto/src/trace_processor/containers/string_pool.h index 11ae91cfeca..58c6db27bd6 100644 --- a/chromium/third_party/perfetto/src/trace_processor/containers/string_pool.h +++ b/chromium/third_party/perfetto/src/trace_processor/containers/string_pool.h @@ -22,6 +22,7 @@ #include #include +#include #include "perfetto/ext/base/optional.h" #include "perfetto/ext/base/paged_memory.h" The command that crashes is: g++ @/home/be/qt5-build/qtwebengine/src/core/debug/QtWebEngineCore_o.rsp -Wl,--start-group @/home/be/qt5-build/qtwebengine/src/core/debug/QtWebEngineCore_a.rsp -Wl,--end-group -Wl,-z,noexecstack -Wl,--fatal-warnings -fPIC -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -m64 -rdynamic -Wl,--enable-new-dtags -Wl,-rpath=/home/be/qt5-installed/lib -Wl,-whole-archive -lqtwebenginecoreapi -Wl,-no-whole-archive -Wl,--no-undefined -Wl,--version-script,QtWebEngineCore.version -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN -shared -Wl,-Bsymbolic-functions -Wl,-soname,libQt5WebEngineCore.so.5 -o libQt5WebEngineCore.so.5.15.3 /home/be/qt5-build/qtdeclarative/lib/libQt5Quick.so /home/be/qt5-build/qtbase/lib/libQt5Gui.so /home/be/qt5-build/qtdeclarative/lib/libQt5QmlModels.so /home/be/qt5-build/qtwebchannel/lib/libQt5WebChannel.so /home/be/qt5-build/qtdeclarative/lib/libQt5Qml.so /home/be/qt5-build/qtbase/lib/libQt5Network.so /home/be/qt5-build/qtlocation/lib/libQt5Positioning.so /home/be/qt5-build/qtbase/lib/libQt5Core.so -lpthread -lGL -lpthread -ldl -lrt -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -levent -lresolv -ljpeg -lm -lopus -lvpx -lpng16 -lz -lwebpmux -lwebpdemux -lwebp -lfreetype -lexpat -lfontconfig -lharfbuzz-subset -lharfbuzz -lre2 -lxkbcommon -ldbus-1 -lpci -lasound -lsnappy -llcms2 -L/home/be/qt5-build/qtwebengine/src/core/api/debug -lGL -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28012] readelf --debug-dump=Ranges doesn't handle concatenated .debug_rnglists sections
https://sourceware.org/bugzilla/show_bug.cgi?id=28012 --- Comment #1 from Simon Marchi --- Created attachment 13512 --> https://sourceware.org/bugzilla/attachment.cgi?id=13512=edit ELF file containing .debug_rnglists -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28012] New: readelf --debug-dump=Ranges doesn't handle concatenated .debug_rnglists sections
https://sourceware.org/bugzilla/show_bug.cgi?id=28012 Bug ID: 28012 Summary: readelf --debug-dump=Ranges doesn't handle concatenated .debug_rnglists sections Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: simark at simark dot ca Target Milestone: --- See attached libstdc++.so.6.0.29, taken from: https://mirror.f4st.host/archlinux/core/os/x86_64/gcc-libs-11.1.0-1-x86_64.pkg.tar.zst (the link may be broken when the package gets upgraded, but it doesn't really matter, the attached file should be enough) It's compiled with gcc, contains DWARF5, and contains a .debug_rnglists section. The .debug_rnglists section is made by concatenating the .debug_rnglists contributions from all .o files, so it's made of multiple range list tables, one after the other (each range list table is described in section 7.28 of DWARF5). It looks like readelf tries to read the whole section as one table or something, because after having displayed the entries of the first table, it shows a bunch of: $ ~/build/binutils-gdb/binutils/readelf --debug-dump=Ranges libstdc++.so.6.0.29 |& less ... 04d8 000a3580 000a359b 04e2 000a35a0 000a35b3 04ec readelf: Warning: Corrupt offset (0x04f9) in range entry 72 readelf: Warning: Corrupt offset (0x04f9) in range entry 73 readelf: Warning: Corrupt offset (0x0509) in range entry 74 ... I tried to debug display_debug_ranges, in binutils/dwarf.c, but I don't really understand what's happening. The code uses num_debug_info_entries, I'm not sure where that is coming from. But I don't see why it would be needed to deal with debug info entries here, I think it should be possible to parse and dump .debug_rnglists by just walking the section by itself until the end. -- You are receiving this mail because: You are on the CC list for the bug.
