[Bug binutils/26349] FAIL: binutils-all/pr25543
https://sourceware.org/bugzilla/show_bug.cgi?id=26349 --- Comment #4 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=d1ce973eb377f19240005665258ce1d89bd064b5 commit d1ce973eb377f19240005665258ce1d89bd064b5 Author: Alan Modra Date: Wed Aug 19 18:19:38 2020 +0930 PR26349, FAIL: binutils-all/pr25543 on hpux The 't' length modifier isn't in SUSv2, unsurprisingly %tx isn't recognized by older printf implementations. So even though 't' is correct for ptrdiff_t we can't use it. Also, _bfd_int64_high and _bfd_int64_low disappeared in 2008. PR 26349 * readelf.c (dump_relocations): Use BFD_VMA_FMT to print offset and info fields. (dump_section_as_strings): Don't use %tx to display offset. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26349] FAIL: binutils-all/pr25543
https://sourceware.org/bugzilla/show_bug.cgi?id=26349 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Alan Modra --- Should now be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26405] New: [objdump, readelf] - PT_OPENBSD_* segments are not recognised.
https://sourceware.org/bugzilla/show_bug.cgi?id=26405 Bug ID: 26405 Summary: [objdump, readelf] - PT_OPENBSD_* segments are not recognised. Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: georgerim at gmail dot com Target Milestone: --- Created attachment 12779 --> https://sourceware.org/bugzilla/attachment.cgi?id=12779&action=edit sample test object with PT_OPENBSD_* segments Currently, both objdump/readelf tools do not recognise PT_OPENBSD_* segments, defined as: PT_OPENBSD_RANDOMIZE = 0x65a3dbe6, // Fill with random data. PT_OPENBSD_WXNEEDED = 0x65a3dbe7, // Program does W^X violations. PT_OPENBSD_BOOTDATA = 0x65a41be6, // Section for boot arguments. E.g., "objdump -p 1.o" prints: Program Header: 0x65a3dbe6 off0x vaddr 0x paddr 0x align 2**0 filesz 0x memsz 0x flags --- 0x65a3dbe7 off0x vaddr 0x paddr 0x align 2**0 filesz 0x memsz 0x flags --- 0x65a41be6 off0x vaddr 0x paddr 0x align 2**0 filesz 0x memsz 0x flags --- The expected output is: OPENBSD_RANDOMIZE off0x vaddr 0x paddr 0x align 2**0 filesz 0x memsz 0x flags --- OPENBSD_WXNEEDED off0x vaddr 0x paddr 0x align 2**0 filesz 0x memsz 0x flags --- OPENBSD_BOOTDATA off0x vaddr 0x paddr 0x align 2**0 filesz 0x memsz 0x flags --- "readelf 1.o --program-headers" prints: Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align LOOS+0x5a3dbe6 0x 0x 0x 0x 0x 0x1 LOOS+0x5a3dbe7 0x 0x 0x 0x 0x 0x1 LOOS+0x5a41be6 0x 0x 0x 0x 0x 0x1 The expected output is: Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align OPENBSD_RANDOMIZE 0x 0x 0x 0x 0x 0x1 OPENBSD_WXNEEDED 0x 0x 0x 0x 0x 0x1 OPENBSD_BOOTDATA 0x 0x 0x 0x 0x 0x1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] New: Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 Bug ID: 26406 Summary: Extreme assembling time regression with 2.35 and master Product: binutils Version: 2.35 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: franz.sirl at lauterbach dot com Target Milestone: --- Hi, I just stumbled over an extreme slowdown in assembler performance. On a 265 MByte .s file (gcc10 assembly output of a 27000 line C source compiled with -O2 -fno-inline + debug + ASAN + UBSAN) the assembler of 2.34 takes ~49-59sec, but the 2.35 assembler takes ~65-74min. Both use about 3.6 GBytes of memory. That's quite a performance regression. fsirl@ds1:~> time as-2.35 --64 -o sample.o sample.s real74m11.921s user73m45.203s sys 0m13.132s fsirl@ds1:~> time as-2.34 --64 -o sample.o sample.s real0m49.454s user0m46.331s sys 0m2.623s Most of the time seems to be spent in _bfd_elf_write_secondary_reloc_section(). The slowdown started with this commit: commit a8e14f4cc2badfcf959f5e2cc57a941dc43f72d4 Author: Nick Clifton Date: Thu Mar 5 15:47:15 2020 + Add support for ELF files which contain multiple reloc sections which all target the same section. Unfortunately I cannot share the testcase, but I can do any requested debugging/testing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 franz.sirl at lauterbach dot com changed: What|Removed |Added CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 franz.sirl at lauterbach dot com changed: What|Removed |Added Build||x86_64-linux-gnu Target||x86_64-linux-gnu Host||x86_64-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 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 gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #1 from Alan Modra --- We're quadratic in number of sections. _bfd_elf_write_object_contents bfd_map_over_sections (abfd, bed->s->write_relocs, &failed); elf_write_relocs: if (!bed->write_secondary_relocs (abfd, sec)) _bfd_elf_write_secondary_reloc_section: for (relsec = abfd->sections; relsec != NULL; relsec = relsec->next) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 --- Comment #2 from franz.sirl at lauterbach dot com --- Well, that would explain it: fsirl@ds1:~> grep '\.section' ~/sample.s |sort -u|wc -l 294085 The testcase was compiled with -ffunction-sections -fdata-sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] New: Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407
Bug ID: 26407
Summary: Global symbol reference breaks without
-Bsymbolic-functions
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: fab...@ritter-vogt.de
Target Milestone: ---
Updating binutils to 2.35 broke libQt5Core5.so.5, QCoreApplication::self didn't
work anymore (https://bugzilla.suse.com/show_bug.cgi?id=1175278#c9).
It's caused by "ld: Handle --dynamic-list* before -Bsymbolic
-Bsymbolic-functions", which effectively means that -Bsymbolic-functions is
ignored if --dynamic-list is given, so the issue can be replicated on 2.34 as
well.
break.i:
void setValue(int v);
extern int value;
int main()
{
setValue(42);
return value;
}
lib.i:
int value = 0;
void setValue(int v) {
value = v;
}
lib.dynlist:
{
extern "C" {
"setValue";
};
};
With -Bsymbolic-functions, it works as expected:
> gcc -fPIC -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,lib.dynlist -o
> lib.so lib.i && readelf --dyn-syms -r lib.so | grep value
3fe8 00060006 R_X86_64_GLOB_DAT 4024 value + 0
6: 4024 4 OBJECT GLOBAL DEFAULT 22 value
> gcc -Wl,--no-undefined lib.so break.i -o break && LD_LIBRARY_PATH=$PWD
> ./break; echo $?
42
Without, the relocation is missing and setValue writes into a different value
than main reads from:
> gcc -fPIC -shared -Wl,--dynamic-list,lib.dynlist -o lib.so lib.i && readelf
> --dyn-syms -r lib.so | grep value
6: 4024 4 OBJECT GLOBAL DEFAULT 22 value
> gcc -Wl,--no-undefined lib.so break.i -o break && LD_LIBRARY_PATH=$PWD
> ./break; echo $?
0
If "value" is mentioned in lib.dynlist or --dynamic-list-data is used it works,
so it seems like objects have to be mentioned in lib.dynlist as well.
But then the symbol should be missing entirely and linking fail, instead of
just the missing relocation resulting in runtime issues, right?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26408] New: A null pointer deference in elf.c:12901:11
https://sourceware.org/bugzilla/show_bug.cgi?id=26408 Bug ID: 26408 Summary: A null pointer deference in elf.c:12901:11 Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: seviezhou at 163 dot com Target Milestone: --- Created attachment 12780 --> https://sourceware.org/bugzilla/attachment.cgi?id=12780&action=edit SEGV-_bfd_elf_write_secondary_reloc_section-elf-12901 ## System info Ubuntu x86_64, clang 6.0, binutils (2.36 d1ce973eb377f19240005665258ce1d89bd064b5) ## Configure CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure ## Command line ./binutils/strip-new -s -g -S -d -w -x -X -v -o /dev/null @@ ## AddressSanitizer output ``` AddressSanitizer:DEADLYSIGNAL = ==68830==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x0069c27f bp 0x7ffd6cec00f0 sp 0x7ffd6cebff40 T0) ==68830==The signal is caused by a READ memory access. ==68830==Hint: address points to the zero page. #0 0x69c27e in _bfd_elf_write_secondary_reloc_section /home/seviezhou/binutils/bfd/elf.c:12901:11 #1 0x642b07 in bfd_elf64_write_relocs /home/seviezhou/binutils/bfd/./elfcode.h:1002:8 #2 0x5d7bbc in bfd_map_over_sections /home/seviezhou/binutils/bfd/section.c:1379:5 #3 0x6847f0 in _bfd_elf_write_object_contents /home/seviezhou/binutils/bfd/elf.c:6657:3 #4 0x5cf909 in bfd_close /home/seviezhou/binutils/bfd/opncls.c:775:13 #5 0x51e9d4 in copy_file /home/seviezhou/binutils/binutils/objcopy.c:3846:51 #6 0x5143d8 in strip_main /home/seviezhou/binutils/binutils/objcopy.c:4826:7 #7 0x5143d8 in main /home/seviezhou/binutils/binutils/objcopy.c:6024 #8 0x7f9cefa3eb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #9 0x41ac99 in _start (/home/seviezhou/binutils/binutils/strip-new+0x41ac99) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/seviezhou/binutils/bfd/elf.c:12901:11 in _bfd_elf_write_secondary_reloc_section ==68830==ABORTING ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 franz.sirl at lauterbach dot com changed: What|Removed |Added CC||franz.sirl at lauterbach dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 --- Comment #3 from Nick Clifton --- Created attachment 12781 --> https://sourceware.org/bugzilla/attachment.cgi?id=12781&action=edit Proposed patch Hi Franz, Please could you try out this patch and let me know if it works for you. It will only improve the performance in the case of linking files which do not contain secondary relocs, but I am assuming that this applies to you. A proper fix, involving chaining the secondary reloc sections together should be written some day, but for now I am hoping that this will do. (Ideally the BFD library's whole support infrastructure for relocs should be rewritten, but that is a huge project). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-08-19 CC||hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING --- Comment #1 from H.J. Lu --- Please make it a run-time test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 --- Comment #2 from Fabian Vogt --- (In reply to H.J. Lu from comment #1) > Please make it a run-time test. Sorry, I don't understand what you mean by that. The break executable only returns 42 with the working lib.so, it doesn't have to be recompiled. FTR, this issue does not happen with gold: # gcc -fuse-ld=gold -fPIC -shared -Wl,--dynamic-list,lib.dynlist -o lib.so lib.i && readelf --dyn-syms -r lib.so | grep value 1fe0 00080006 R_X86_64_GLOB_DAT 2014 value + 0 8: 2014 4 OBJECT GLOBAL DEFAULT 24 value # LD_LIBRARY_PATH=$PWD ./break; echo $? 42 -- You are receiving this mail because: You are on the CC list for the bug.
