[Bug ld/20796] New: m68k binutils produce R_68K_NONE relocations in .rela.plt. Causes glibc to fail to load binaries.
https://sourceware.org/bugzilla/show_bug.cgi?id=20796
Bug ID: 20796
Summary: m68k binutils produce R_68K_NONE relocations in
.rela.plt. Causes glibc to fail to load binaries.
Product: binutils
Version: 2.28 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
How to reproduce. We will need to build a shared library and an executable.
//Executable source:
// a.c
#include
int main(void) {
printf ("hello!\n");
return 0;
}
//Library source:
// b.c
void buggy_symbol (void)
{
return;
}
Building:
Compiling...
$ m68k-unknown-linux-gnu-gcc -c a.c -o a.o
$ m68k-unknown-linux-gnu-gcc -shared -fPIC b.c -o libb.so
Linking...
$ m68k-unknown-linux-gnu-gcc -L. -Wl,--gc-sections '-Wl,-rpath=$ORIGIN' -u
buggy_symbol a.o -o bug -lb
Running...
$ ./bug
./bug: error while loading shared libraries: unexpected PLT reloc type 0x00
$ LD_BIND_NOW=1 ./bug
hello!
$ readelf -a bug | egrep 'R_68K_NONE|Relocation section'
Relocation section '.rela.dyn' at offset 0x38c contains 3 entries:
R_68K_NONE 0
R_68K_NONE 0
Relocation section '.rela.plt' at offset 0x3b0 contains 5 entries:
R_68K_NONE 0
The sample is a distilled failure of GHC build failure.
GHC adds '-u buggy_symbol' when links both libraries and executables but
executables don't require it.
Workarounds so far. Any of there does work:
- add -Wl,-z,now
- drop -Wl,--gc-sections
- drop -u buggy_symbol
Binutils version: 2.27.51.20161105
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20796] m68k binutils produce R_68K_NONE relocations in .rela.plt. Causes glibc to fail to load binaries.
https://sourceware.org/bugzilla/show_bug.cgi?id=20796 Sergei Trofimovich changed: What|Removed |Added CC||sch...@linux-m68k.org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20797] New: m68k binutils produce R_68K_NONE relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=20797
Bug ID: 20797
Summary: m68k binutils produce R_68K_NONE relocations
Product: binutils
Version: 2.28 (HEAD)
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
It's a long known bug without real known impact.
I have not found bugzilla entry for it thus documenting
it here. Maybe it will get fix one day.
binutils has a "FIXME" comment about it:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-m68k.c;h=7c2e0fcca3bfb35d71dc1431c69958c84f04de7b;hb=HEAD#l3356
3356 /* Allocate memory for the section contents. */
3357 /* FIXME: This should be a call to bfd_alloc not bfd_zalloc.
3358 Unused entries should be reclaimed before the section's contents
3359 are written out, but at the moment this does not happen. Thus in
3360 order to prevent writing out garbage, we initialise the section's
3361 contents to zero. */
3362 s->contents = (bfd_byte *) bfd_zalloc (dynobj, s->size);
And glibc has a workaround to allow such relocations (but only of non-lazy
type):
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=sysdeps/m68k/dl-machine.h;h=41c179c3f13329f61a4b16e917e4037aa4545d5e;hb=HEAD#l290
290 case R_68K_NONE:/* Alright, Wilbur. */
291 break;
How to reproduce:
$ echo 'int main(){}' > a.c
$ m68k-unknown-linux-gnu-gcc a.c -o a
$ readelf -a a | egrep 'R_68K_NONE|Relocation section'
Relocation section '.rela.dyn' at offset 0x238 contains 3 entries:
R_68K_NONE 0
R_68K_NONE 0
Relocation section '.rela.plt' at offset 0x25c contains 2 entries:
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20797] m68k binutils produce R_68K_NONE relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=20797 Sergei Trofimovich changed: What|Removed |Added CC||sch...@linux-m68k.org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21518] New: ld.gold should igmore -pie flag for --oformat=binary mode (ld.bfd does)
https://sourceware.org/bugzilla/show_bug.cgi?id=21518 Bug ID: 21518 Summary: ld.gold should igmore -pie flag for --oformat=binary mode (ld.bfd does) Product: binutils Version: 2.27 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: slyfox at inbox dot ru CC: ian at airs dot com Target Milestone: --- It came up as a build failure of dosemu on gcc-7 with --enable-default-pie: https://bugs.gentoo.org/show_bug.cgi?id=618366 Simple reproducer (imagine '-pie' is a default): $ cat a.S .text .code16 .globl _start16 _start16: # this works $ gcc -pie -fuse-ld=gold -Wl,-Ttext,100,-e,_start16,--oformat,binary -nostdlib -s -o foo.com a.S /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: fatal error: binary output format not compatible with -shared or -pie or -r collect2: error: ld returned 1 exit status # this fails $ gcc -pie -fuse-ld=bfd -Wl,-Ttext,100,-e,_start16,--oformat,binary -nostdlib -s -o foo.com a.S Arguably '-pie' has no role here as the output format is not really an ELF. $ x86_64-pc-linux-gnu-ld.gold --version GNU gold (Gentoo 2.27 p1.0 2.27) 1.12 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21518] ld.gold should ignmore -pie flag for --oformat=binary mode (ld.bfd does)
https://sourceware.org/bugzilla/show_bug.cgi?id=21518 Sergei Trofimovich changed: What|Removed |Added Summary|ld.gold should igmore -pie |ld.gold should ignmore -pie |flag for --oformat=binary |flag for --oformat=binary |mode (ld.bfd does) |mode (ld.bfd does) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21669] New: strip from binutils-2.28 SIGSEGVs when strips ia64 files
https://sourceware.org/bugzilla/show_bug.cgi?id=21669 Bug ID: 21669 Summary: strip from binutils-2.28 SIGSEGVs when strips ia64 files Product: binutils Version: 2.29 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Noticed when built gcc-6.3.0 and gcc-5.4.0 with bintils-2.28 (original report https://bugs.gentoo.org/show_bug.cgi?id=622500 ) In the build process of gcc the following object file is generated that can crash 'strip': http://dev.gentoo.org/~slyfox/bugs/622500-ia64-strip/dwarf2out.o Reproducible both on native ia64 box and when running cross-binutils on x85_64. -fsanitize=address detects out-of-bouds access as: ==17093==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61a00598 ... READ of size 8 at 0x61a00598 thread T0 #0 0x7feeb6dd4333 in find_link binutils-gdb/bfd/elf.c:1295 #1 0x7feeb6dd48a1 in copy_special_section_fields binutils-gdb/bfd/elf.c:1379 #2 0x7feeb6dd5391 in _bfd_elf_copy_private_bfd_data binutils-gdb/bfd/elf.c:1501 #3 0x5623789a0952 in copy_object binutils-gdb/binutils/objcopy.c:2974 #4 0x5623789a25d4 in copy_file binutils-gdb/binutils/objcopy.c:3336 #5 0x5623789a6856 in strip_main binutils-gdb/binutils/objcopy.c:4261 #6 0x5623789ab0f9 in main binutils-gdb/binutils/objcopy.c:5368 #7 0x7feeb650f3f9 in __libc_start_main (/lib64/libc.so.6+0x39648203f9) #8 0x562378996259 in _start (binutils-gdb/binutils/.libs/strip-new+0x16259) The failure is easy to workaround but i'm not sure if comething breaks hint invariant: diff --git a/bfd/elf.c b/bfd/elf.c index 5f37e7f79c..abb1499893 100644 --- a/bfd/elf.c +++ b/bfd/elf.c @@ -1291,7 +1291,8 @@ find_link (const bfd * obfd, const Elf_Internal_Shdr * iheader, const unsigned i BFD_ASSERT (iheader != NULL); /* See PR 20922 for a reproducer of the NULL test. */ - if (oheaders[hint] != NULL + if (hint < elf_numsections (obfd) + && oheaders[hint] != NULL && section_match (oheaders[hint], iheader)) return hint; -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21669] strip from binutils-2.28 SIGSEGVs when strips ia64 files
https://sourceware.org/bugzilla/show_bug.cgi?id=21669 Sergei Trofimovich changed: What|Removed |Added Target||ia64-unknown-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21669] strip from binutils-2.28 SIGSEGVs when strips ia64 files
https://sourceware.org/bugzilla/show_bug.cgi?id=21669 --- Comment #1 from Sergei Trofimovich --- Created attachment 10219 --> https://sourceware.org/bugzilla/attachment.cgi?id=10219&action=edit binutils-2.28-bfd-elf.c-fix-out-of-bounds-access-in-find_link.patch binutils-2.28-bfd-elf.c-fix-out-of-bounds-access-in-find_link.patch is the same workaround as a separate patch. The patch allows rebuilding gcc-6.3.0 on ia64. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21669] strip from binutils-2.28 SIGSEGVs when strips ia64 files
https://sourceware.org/bugzilla/show_bug.cgi?id=21669 Sergei Trofimovich changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Sergei Trofimovich --- Adding Nick who handled very similar PR 20922 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21669] strip from binutils-2.28 SIGSEGVs when strips ia64 files
https://sourceware.org/bugzilla/show_bug.cgi?id=21669 Sergei Trofimovich changed: What|Removed |Added URL||https://sourceware.org/ml/b ||inutils/2017-06/msg00328.ht ||ml --- Comment #3 from Sergei Trofimovich --- Sent patch for review as https://sourceware.org/ml/binutils/2017-06/msg00328.html -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21677] ld 2.27 has unexplained 10x performance improvement in some cases
https://sourceware.org/bugzilla/show_bug.cgi?id=21677 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #2 from Sergei Trofimovich --- I suggest running ld under 'perf record' / 'perf report' to get the idea where ld used to spend time. Maybe it will shed some light. Otherwise bisection is always an option. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/16177] R_ARM_COPY reloc generated for reference in writable section
https://sourceware.org/bugzilla/show_bug.cgi?id=16177 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22067] New: ld SIGSEGVs when links memtest86+: gldelf_x86_64_place_orphan
https://sourceware.org/bugzilla/show_bug.cgi?id=22067
Bug ID: 22067
Summary: ld SIGSEGVs when links memtest86+:
gldelf_x86_64_place_orphan
Product: binutils
Version: 2.29
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 10388
--> https://sourceware.org/bugzilla/attachment.cgi?id=10388&action=edit
memtest-repro.tar.gz
The command (All binaries are attached in memtest-repro.tar.gz):
$ ld -T memtest.bin.lds bootsect.o setup.o -b binary memtest_shared.bin -o
memtest.bin
$ gdb --quiet /usr/bin/ld core.15679
Reading symbols from /usr/bin/ld...Reading symbols from
/usr/lib64/debug//usr/x86_64-pc-linux-gnu/binutils-bin/2.29/ld.debug...done.
done.
[New LWP 15679]
Core was generated by `ld -T memtest.bin.lds bootsect.o setup.o -b binary
memtest_shared.bin -o memtes'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x55b7313ca4d1 in gldelf_x86_64_place_orphan (s=0x55b73198b8c8,
secname=0x55b7319c0973 ".text", constraint=382) at eelf_x86_64.c:1990
1990&& (elf_section_data (os->bfd_section)->this_hdr.sh_info
(gdb) bt full
#0 0x55b7313ca4d1 in gldelf_x86_64_place_orphan (s=0x55b73198b8c8,
secname=0x55b7319c0973 ".text", constraint=382) at eelf_x86_64.c:1990
hold = {{name = 0x55b731413168 ".text", flags = 283, os =
0x55b731962ca0, section = 0x55b73196e700, stmt = 0x55b731962e00, os_tail =
0x55b731962e20}, {
name = 0x55b73141315a ".rodata", flags = 299, os = 0x0, section =
0x0, stmt = 0x0, os_tail = 0x0}, {name = 0x55b7314131ad ".tdata", flags = 1315,
os = 0x0, section = 0x0,
stmt = 0x0, os_tail = 0x0}, {name = 0x55b73141314e ".data", flags =
291, os = 0x0, section = 0x0, stmt = 0x0, os_tail = 0x0}, {name =
0x55b731413143 ".bss", flags = 1, os = 0x0,
section = 0x55b73196e830, stmt = 0x55b731962eb0, os_tail =
0x55b731962ed0}, {name = 0x0, flags = 299, os = 0x0, section = 0x0, stmt = 0x0,
os_tail = 0x0}, {
name = 0x55b7314131b4 ".interp", flags = 299, os = 0x0, section =
0x0, stmt = 0x0, os_tail = 0x0}, {name = 0x55b7314131bc ".sdata", flags =
4194595, os = 0x0, section = 0x0,
stmt = 0x0, os_tail = 0x0}, {name = 0x55b7314131c3 ".comment",
flags = 256, os = 0x0, section = 0x0, stmt = 0x0, os_tail = 0x0}}
orphan_init_done = 1
place =
after =
os = 0x55b731962e00
match_by_name = 0x0
isdyn =
iself = 1
sh_type = 1
flags =
nexts =
#1 0x55b73109efd7 in ldlang_place_orphan (s=0x55b73198b8c8) at
/usr/src/debug/sys-devel/binutils-2.29/binutils-2.29/ld/ldlang.c:6376
os =
name = 0x55b7319c0973 ".text"
constraint = 0
#2 lang_place_orphans () at
/usr/src/debug/sys-devel/binutils-2.29/binutils-2.29/ld/ldlang.c:6433
s = 0x55b73198b8c8
file = 0x55b73196cfa0
#3 lang_process () at
/usr/src/debug/sys-devel/binutils-2.29/binutils-2.29/ld/ldlang.c:7147
No locals.
#4 0x55b73108c308 in main (argc=, argv=) at
/usr/src/debug/sys-devel/binutils-2.29/binutils-2.29/ld/ldmain.c:445
start_time = 2365
start_sbrk = 0x55b731961000 ""
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22067] ld SIGSEGVs when links memtest86+: gldelf_x86_64_place_orphan
https://sourceware.org/bugzilla/show_bug.cgi?id=22067 --- Comment #1 from Sergei Trofimovich --- Running ld from master under valgrind suggests the out-of-bounds access is still there: $ valgrind --quiet /home/slyfox/dev/git/binutils-gdb-x86_64/ld/ld-new -T memtest.bin.lds bootsect.o setup.o -b binary memtest_shared.bin -o memtest.bin ==15789== Invalid read of size 4 ==15789==at 0x194D98: _bfd_x86_elf_link_check_relocs (elfxx-x86.c:826) ==15789==by 0x152A2A: lang_check_relocs (ldlang.c:7052) ==15789==by 0x152A2A: lang_process (ldlang.c:7260) ==15789==by 0x1407A3: main (ldmain.c:432) ==15789== Address 0x5411738 is 0 bytes after a block of size 72 alloc'd ==15789==at 0x4C2CEAF: malloc (vg_replace_malloc.c:299) ==15789==by 0x17DA02: bfd_malloc (libbfd.c:193) ==15789==by 0x17EC92: _bfd_generic_link_hash_table_create (linker.c:753) ==15789==by 0x14EA47: open_output (ldlang.c:3184) ==15789==by 0x14EA47: ldlang_open_output (ldlang.c:3198) ==15789==by 0x14C18F: lang_for_each_statement_worker (ldlang.c:958) ==15789==by 0x1524BF: lang_for_each_statement (ldlang.c:1001) ==15789==by 0x1524BF: lang_process (ldlang.c:7094) ==15789==by 0x1407A3: main (ldmain.c:432) ==15789== -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22626] New: [bisected] ld -pie produces invalid relocations on powerpc-unknown-linux-gnu-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=22626 Bug ID: 22626 Summary: [bisected] ld -pie produces invalid relocations on powerpc-unknown-linux-gnu-gcc Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Original bug: https://bugs.gentoo.org/641474#c4 The issue manifests as non-working binary when gcc is built with --enable-default-pie. $ powerpc-unknown-linux-gnu-gcc a.c -o a /usr/libexec/gcc/powerpc-unknown-linux-gnu/ld: warning: creating a DT_TEXTREL in a shared object. $ ./a Segmentation fault $ readelf -a a Relocation section '.rela.dyn' at offset 0x2a0 contains 33 entries: Offset InfoTypeSym.Value Sym. Name + Addend ... 04e2 0906 R_PPC_ADDR16_HA readelf: Error: bad symbol index: 0009 in reloc 04ea 0904 R_PPC_ADDR16_LO readelf: Error: bad symbol index: 0009 in reloc 0512 0906 R_PPC_ADDR16_HA readelf: Error: bad symbol index: 0009 in reloc 051a 0904 R_PPC_ADDR16_LO readelf: Error: bad symbol index: 0009 in reloc It looks like .rela.dyn refer to already garbage-collected symbols. I've bisected it down to the following commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=6b3b0ab89663306d17927d630304dbbd36e84570 """Linker assigned symbols should be made dynamic by default only when creating shared object or relocatable executable.""" Last working: 2.26.1 Tested broken: 2.27, 2.28.1 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22626] [bisected] ld -pie produces invalid relocations on powerpc-unknown-linux-gnu-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=22626 Sergei Trofimovich changed: What|Removed |Added Target||powerpc-unknown-linux-gnu CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22626] [bisected] ld -pie produces invalid relocations on powerpc-unknown-linux-gnu-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=22626 --- Comment #2 from Sergei Trofimovich --- Same for master from commit 390c91cfcffe1a0d75b6100d1542cda2544993b3 (HEAD -> master, origin/master, origin/HEAD) Author: H.J. Lu Date: Sun Dec 17 09:40:54 2017 -0800 x86: Check pseudo prefix without instruction built as: $ ../binutils-gdb/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc-unknown-linux-gnu --disable-werror tested as (exact linker invocation): ./link-dev.sh GNU ld (GNU Binutils) 2.29.51.20171217 Supported emulations: elf32ppclinux elf32ppc elf32ppcsim elf32lppclinux elf32lppc elf32lppcsim elf64ppc elf64lppc 0502 0906 R_PPC_ADDR16_HA readelf: Error: bad symbol index: 0009 in reloc 050a 0904 R_PPC_ADDR16_LO readelf: Error: bad symbol index: 0009 in reloc 0532 0906 R_PPC_ADDR16_HA readelf: Error: bad symbol index: 0009 in reloc 053a 0904 R_PPC_ADDR16_LO readelf: Error: bad symbol index: 0009 in reloc $ cat ./link-dev.sh #!/bin/bash ld/ld-new \ --sysroot=/usr/powerpc-unknown-linux-gnu \ --eh-frame-hdr \ -V \ --secure-plt \ -m elf32ppclinux \ -dynamic-linker /lib/ld.so.1 \ -pie \ -o a \ /usr/powerpc-unknown-linux-gnu/usr/lib/../lib/crt1.o \ /usr/powerpc-unknown-linux-gnu/usr/lib/../lib/crti.o \ /usr/lib/gcc/powerpc-unknown-linux-gnu/7.2.0/crtbegin.o \ -L/usr/lib/gcc/powerpc-unknown-linux-gnu/7.2.0 \ -L/usr/lib/gcc/powerpc-unknown-linux-gnu/7.2.0/../../../../powerpc-unknown-linux-gnu/lib/../lib \ -L/usr/powerpc-unknown-linux-gnu/lib/../lib \ -L/usr/powerpc-unknown-linux-gnu/usr/lib/../lib \ -L/usr/lib/gcc/powerpc-unknown-linux-gnu/7.2.0/../../../../powerpc-unknown-linux-gnu/lib \ -L/usr/powerpc-unknown-linux-gnu/lib \ -L/usr/powerpc-unknown-linux-gnu/usr/lib \ \ a.o \ \ -lgcc \ --as-needed -lgcc_s --no-as-needed \ -lc -lgcc \ --as-needed -lgcc_s --no-as-needed \ /usr/lib/gcc/powerpc-unknown-linux-gnu/7.2.0/crtend.o \ /usr/powerpc-unknown-linux-gnu/usr/lib/../lib/crtn.o LANG=C readelf -a ./a >log 2>&1 fgrep 'bad symbol index' log -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22626] [bisected] ld -pie produces invalid relocations on powerpc-unknown-linux-gnu-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=22626
--- Comment #3 from Sergei Trofimovich ---
Original program is:
int main(){}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22626] [bisected] ld -pie produces invalid relocations on powerpc-unknown-linux-gnu-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=22626 --- Comment #6 from Sergei Trofimovich --- (In reply to Alan Modra from comment #5) > If you cannot reproduce the problem with a --disable-default-pie compiler by > using the appropriate combination of options (-pie -fPIE), then the problem > lies in the compiler. In comment #2, I see crt1.o and crtbegin.o in the > list of object files passed to ld. That is wrong for a PIE. It should be > Scrt1.o and crtbeginS.o. > > The compiler problem should have been fixed with git commit a9b2df6c for gcc > master, f5c42d1b for gcc-7-branch, and e764842a for gcc-6-branch. > > The PR driver/81523 patches are important too. Aha, thank you! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22626] [bisected] ld -pie produces invalid relocations on powerpc-unknown-linux-gnu-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=22626 --- Comment #7 from Sergei Trofimovich --- (In reply to Alan Modra from comment #5) > If you cannot reproduce the problem with a --disable-default-pie compiler by > using the appropriate combination of options (-pie -fPIE), then the problem > lies in the compiler. In comment #2, I see crt1.o and crtbegin.o in the > list of object files passed to ld. That is wrong for a PIE. It should be > Scrt1.o and crtbeginS.o. > > The compiler problem should have been fixed with git commit a9b2df6c for gcc > master, f5c42d1b for gcc-7-branch, and e764842a for gcc-6-branch. > > The PR driver/81523 patches are important too. One more question: is it expected that ld generates final binary relocations to nonexisting symbols? I would expect ld to fail to link instead of producing bad binary. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22706] New: bfd/elf32-sh.c fails asserts without additional information: sh4-unknown-linux-gnu-ld: BFD assertion fail bfd/elf32-sh.c:5171
https://sourceware.org/bugzilla/show_bug.cgi?id=22706
Bug ID: 22706
Summary: bfd/elf32-sh.c fails asserts without additional
information: sh4-unknown-linux-gnu-ld: BFD assertion
fail bfd/elf32-sh.c:5171
Product: binutils
Version: 2.30 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Attempted to build glibc for sh4-unknown-linux-gnu target and got the following
errors:
LANG=C bash -x ./trigger-linker-system.sh
+ sh4-unknown-linux-gnu-ld -plugin
/usr/libexec/gcc/sh4-unknown-linux-gnu/6.4.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/sh4-unknown-linux-gnu/6.4.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccvxcoL0.res --sysroot=/usr/sh4-unknown-linux-gnu
-m shlelf_linux -static -o
/tmp/portage/cross-sh4-unknown-linux-gnu/glibc-/work/build-default-sh4-unknown-linux-gnu-nptl/elf/sln
-L/usr/lib/gcc/sh4-unknown-linux-gnu/6.4.0
-L/usr/lib/gcc/sh4-unknown-linux-gnu/6.4.0/../../../../sh4-unknown-linux-gnu/lib
-L/usr/sh4-unknown-linux-gnu/lib -L/usr/sh4-unknown-linux-gnu/usr/lib -O1
--as-needed --hash-style=gnu
/tmp/portage/cross-sh4-unknown-linux-gnu/glibc-/work/build-default-sh4-unknown-linux-gnu-nptl/csu/crt1.o
/tmp/portage/cross-sh4-unknown-linux-gnu/glibc-/work/build-default-sh4-unknown-linux-gnu-nptl/csu/crti.o
/usr/lib/gcc/sh4-unknown-linux-gnu/6.4.0/crtbeginT.o
/tmp/portage/cross-sh4-unknown-linux-gnu/glibc-/work/build-default-sh4-unknown-linux-gnu-nptl/elf/sln.o
/tmp/portage/cross-sh4-unknown-linux-gnu/glibc-/work/build-default-sh4-unknown-linux-gnu-nptl/elf/static-stubs.o
--start-group
/tmp/portage/cross-sh4-unknown-linux-gnu/glibc-/work/build-default-sh4-unknown-linux-gnu-nptl/libc.a
-lgcc --end-group /usr/lib/gcc/sh4-unknown-linux-gnu/6.4.0/crtend.o
/tmp/portage/cross-sh4-unknown-linux-gnu/glibc-/work/build-default-sh4-unknown-linux-gnu-nptl/csu/crtn.o
sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.29.1 p3) 2.29.1 assertion fail
/tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.29.1-r1/work/binutils-2.29.1/bfd/elf32-sh.c:5171
sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.29.1 p3) 2.29.1 assertion fail
/tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.29.1-r1/work/binutils-2.29.1/bfd/elf32-sh.c:5174
sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.29.1 p3) 2.29.1 assertion fail
/tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.29.1-r1/work/binutils-2.29.1/bfd/elf32-sh.c:5176
...
The trigger issue here is likely glibc's lack of support gcc built as
--enable-default-pie but binutils ld error messages are not informative enough
to understand what is wrong with the code.
It's caused by BFD_ASSERT calls at:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-sh.c;h=9fa363615ddbb7629628b7fe500df93d0a27a8b0;hb=HEAD#l5141
I suggest changing calls like
BFD_ASSERT ((insn & 0xff00) == 0xd000);
to something like
if ((insn & 0xff00) != 0xd000)
_bfd_error_handler
/* xgettext:c-format */
(_("%B(%A+%#Lx): unexpected instruction %04X (expected 0xd0??, ?)"),
input_bfd, input_section, offset, insn);
That way error message would be:
ld/ld-new: libc.a(sched_yield.o)(.text+0x3a): unexpected instruction A005
(expected 0xd0??, mov.l)
ld/ld-new: libc.a(sched_yield.o)(.text+0x3c): unexpected instruction E0FF
(expected 0x0?12, stc)
ld/ld-new: libc.a(sched_yield.o)(.text+0x3e): unexpected instruction 0009
(expected 0x0?ce, mov.l)
It will help tweaking glibc.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15891] ia64, ld segfault on --as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=15891 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22828] New: [patch] incorrect format string in ru.po causes SIGSEGVs on warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=22828 Bug ID: 22828 Summary: [patch] incorrect format string in ru.po causes SIGSEGVs on warnings Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Created attachment 10800 --> https://sourceware.org/bugzilla/attachment.cgi?id=10800&action=edit 0001-ru.po-fix-format-string-in-russian-locale.patch Example crash looks like that (locale output has to be LANG=ru_RU) $ /usr/libexec/gcc/nios2-unknown-linux-gnu/ld -plugin /usr/libexec/gcc/nios2-unknown-linux-gnu/7.2.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/nios2-unknown-linux-gnu/7.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccvHyCfr.res --sysroot=/usr/nios2-unknown-linux-gnu --eh-frame-hdr -EL -shared -o /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/ld.so.new -L/usr/lib/gcc/nios2-unknown-linux-gnu/7.2.0 -L/usr/lib/gcc/nios2-unknown-linux-gnu/7.2.0/../../../../nios2-unknown-linux-gnu/lib -L/usr/nios2-unknown-linux-gnu/lib -L/usr/nios2-unknown-linux-gnu/usr/lib -O1 --as-needed --hash-style=gnu -z combreloc -z relro -z defs -z now /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os --version-script=/tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/ld.map -soname=ld-linux-nios2.so.1 -defsym=_begin=0 /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: из-за кодировки FDE в /tmp/portage/cross-nios2-unknown-linux-gnu/glibc-/work/build-default-nios2-unknown-linux-gnu-nptl/elf/librtld.os(.eh_frame) таблица .eh_frame_hdr создана не будет. /usr/libexec/gcc/nios2-unknown-linux-gnu/ld: в дальнейшем предупреждения о не создании таблицы .eh_frame_hdr из-за кодировки FDE в /usr/libexec/gcc/nios2-unknown-linux-gnu/ld generated(Ошибка сегментирования (стек памяти сброшен на диск) Basically the wole fix is to remove extra format args: #: elf-eh-frame.c:1544 msgid "%P: Further warnings about FDE encoding preventing .eh_frame_hdr generation dropped.\n" -msgstr "%P: в дальнейшем предупреждения о не создании таблицы .eh_frame_hdr из-за кодировки FDE в %B(%A) будут отбрасываться.\n" +msgstr "%P: в дальнейшем предупреждения о не создании таблицы .eh_frame_hdr из-за кодировки FDE будут отбрасываться.\n" -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22828] [patch] incorrect format string in ru.po causes SIGSEGVs on warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=22828 Sergei Trofimovich changed: What|Removed |Added CC||nickc at sourceware dot org --- Comment #1 from Sergei Trofimovich --- The translation string was added in 7d73b4c8dfc8ae59dc1334e67c7ae2ea493dd121 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22909] New: Expand --warn-shared-textrel support to all executables, not only PIC objects
https://sourceware.org/bugzilla/show_bug.cgi?id=22909 Bug ID: 22909 Summary: Expand --warn-shared-textrel support to all executables, not only PIC objects Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Gentoo enables --warn-shared-textrel by default for and extends warning to all dynamic executables (PIE or not): https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/binutils/2.17/66_all_binutils-2.17.50.0.2-warn-textrel.patch?revision=1.1&view=markup What do you think of extending this option (or adding new one) to cover executables in upstream binutils? Something like --warn-textrel. Lack of TEXTREL warning came up recently in gcc where gcc was built with TEXTRELs due to a platform-specific gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 The warning would be complementary to '-Wl,-z,-text' which converts problems of this kind to errors. Related bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20824 : "enable warn-shared-textrel by default". -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22909] Expand --warn-shared-textrel support to all executables, not only PIC objects
https://sourceware.org/bugzilla/show_bug.cgi?id=22909
--- Comment #2 from Sergei Trofimovich ---
I was not able to force x86 targets to generate TEXTREL executables.
Best I could do is to emit pseudo textrel but it does not cause TEXTREL section
creation:
// a.c
#include
int _start() {
__asm__ volatile (
".Ltext_reloc:"
".reloc .Ltext_reloc - _start, R_386_32, printf\n"
".long 0x90909090\n"
);
}
$ gcc -m32 a.c -O2 -o a -rdynamic -no-pie -nostdlib -lc -Wl,-q
Is there a way to force printf symbol ot be resolved to absolute address
instead of .plt?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23207] New: hppa ld SIGSEGVs on invalid object files:
https://sourceware.org/bugzilla/show_bug.cgi?id=23207
Bug ID: 23207
Summary: hppa ld SIGSEGVs on invalid object files:
Product: binutils
Version: 2.30
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 11031
--> https://sourceware.org/bugzilla/attachment.cgi?id=11031&action=edit
bug.o
Original bug found on libressl: https://bugs.gentoo.org/656104
libressl itself has a bug that triggers binutils SIGSEGV.
See fix if you are interested:
https://github.com/libressl-portable/portable/pull/426
Steps to reproduce:
Source file:
// $ cat bug.i
__asm__(".section .gnu.warning.");
a() { b(); }
Build as:
$ hppa2.0-unknown-linux-gnu-gcc -fPIC -c bug.i -o bug.o
$ hppa2.0-unknown-linux-gnu-gcc -shared -fPICbug.o -o libbug.so
...
collect2: fatal error: ld terminated with signal 11 [Segmentation fault],
core dumped
bug.o is also attached.
gdb backtrace:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f761db022b4 in sprintf (__fmt=0x7f761db67feb "%08x_%s+%x",
__s=0x55a62a3c5fb0 "\020p<*\246U") at /usr/include/bits/stdio2.h:33
33return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
(gdb) bt
#0 0x7f761db022b4 in sprintf (__fmt=0x7f761db67feb "%08x_%s+%x",
__s=0x55a62a3c5fb0 "\020p<*\246U") at /usr/include/bits/stdio2.h:33
#1 hppa_stub_name (hh=hh@entry=0x55a62a1d1040, rela=,
rela=, sym_sec=, input_section=)
at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/bfd/elf32-hppa.c:468
#2 0x7f761db02399 in hppa_get_stub_entry (sym_sec=sym_sec@entry=0x0,
hh=hh@entry=0x55a62a1d1040, rela=rela@entry=0x55a62a200b20,
htab=htab@entry=0x55a62a1cfe90, input_section=)
at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/bfd/elf32-hppa.c:517
#3 0x7f761db045ab in final_link_relocate (info=0x55a629ef2a60 ,
hh=0x55a62a1d1040, sym_sec=, htab=0x55a62a1cfe90,
value=, rela=0x55a62a200b20, contents=0x55a62a402aa0
"k\302?\331\b\003\002A\b\036\002Co\301", input_section=0x55a62a1fe920)
at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/bfd/elf32-hppa.c:3274
#4 elf32_hppa_relocate_section (output_bfd=output_bfd@entry=0x55a62a1cdb00,
info=0x55a629ef2a60 ,
input_bfd=input_bfd@entry=0x55a62a1eac50,
input_section=input_section@entry=0x55a62a1fe920,
contents=0x55a62a402aa0 "k\302?\331\b\003\002A\b\036\002Co\301",
relocs=relocs@entry=0x55a62a200b20, local_syms=0x55a62a1fc1a0,
local_sections=0x55a62a402fa0) at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/bfd/elf32-hppa.c:4174
#5 0x7f761db2bb60 in elf_link_input_bfd
(flinfo=flinfo@entry=0x7fffab228070, input_bfd=input_bfd@entry=0x55a62a1eac50)
at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/bfd/elflink.c:10715
#6 0x7f761db2d6af in bfd_elf_final_link () at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/bfd/elflink.c:12033
#7 0x7f761db0553b in elf32_hppa_final_link (abfd=0x55a62a1cdb00,
info=0x55a629ef2a60 )
at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/bfd/elf32-hppa.c:3143
#8 0x55a629c9541f in ldwrite () at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/ld/ldwrite.c:581
#9 0x55a629c7df30 in main (argc=, argv=)
at
/usr/src/debug/cross-hppa2.0-unknown-linux-gnu/binutils-2.30-r2/binutils-2.30/ld/ldmain.c:456
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23207] hppa ld SIGSEGVs on invalid object files: bfd/elf32-hppa.c:468 : hppa_get_stub_entry()
https://sourceware.org/bugzilla/show_bug.cgi?id=23207 Sergei Trofimovich changed: What|Removed |Added Summary|hppa ld SIGSEGVs on invalid |hppa ld SIGSEGVs on invalid |object files: |object files: ||bfd/elf32-hppa.c:468 : ||hppa_get_stub_entry() -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23207] hppa ld SIGSEGVs on invalid object files: bfd/elf32-hppa.c:468 : hppa_get_stub_entry()
https://sourceware.org/bugzilla/show_bug.cgi?id=23207 --- Comment #1 from Sergei Trofimovich --- Minimal reproducer does not require any external objects: $ hppa2.0-unknown-linux-gnu-ld -shared -o libbug.so bug.o -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23207] hppa ld SIGSEGVs on invalid object files: bfd/elf32-hppa.c:468 : hppa_get_stub_entry()
https://sourceware.org/bugzilla/show_bug.cgi?id=23207 --- Comment #4 from Sergei Trofimovich --- Created attachment 11033 --> https://sourceware.org/bugzilla/attachment.cgi?id=11033&action=edit bug-2.o -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23207] hppa ld SIGSEGVs on invalid object files: bfd/elf32-hppa.c:468 : hppa_get_stub_entry()
https://sourceware.org/bugzilla/show_bug.cgi?id=23207
--- Comment #3 from Sergei Trofimovich ---
(In reply to cvs-com...@gcc.gnu.org from comment #2)
> The master branch has been updated by Alan Modra :
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=7455c018e45766ab7193cbd45f98f781e0dc7d84
>
> commit 7455c018e45766ab7193cbd45f98f781e0dc7d84
> Author: Alan Modra
> Date: Mon May 21 21:29:25 2018 +0930
This seems to fix the minimal reproducer, but not original bug. ld still
SIGSEGVs. Bigger minimal file that still SIGSEGVs:
// $ cat bug.i
a() { b(); }
__asm__(".section .gnu.warning.");
c() { b(); }
Same steps to reproduce:
$ hppa2.0-unknown-linux-gnu-gcc -fPIC -c bug.i -o bug.o
$ hppa2.0-unknown-linux-gnu-gcc -shared -fPICbug.o -o libbug.so
Will attach bigger object file as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23207] hppa ld SIGSEGVs on invalid object files: bfd/elf32-hppa.c:468 : hppa_get_stub_entry()
https://sourceware.org/bugzilla/show_bug.cgi?id=23207 --- Comment #5 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #4) > Created attachment 11033 [details] > bug-2.o crash backtrace for it: $ gdb --args ~/dev/git/binutils-gdb-hppa2.0/ld/ld-new -shared -o libbug.so bug.o ... (gdb) bt #0 0x555c980b in hppa_stub_name (input_section=0x0, sym_sec=0x0, hh=0x55906b50, rela=0x5591f8d0) at ../../binutils-gdb/bfd/elf32-hppa.c:469 #1 0x555cdd61 in elf32_hppa_size_stubs (output_bfd=0x55903f20, stub_bfd=0x55918580, info=0x558ebd20 , multi_subspace=0, group_size=1, add_stub_section=0x555a2b59 , layout_sections_again=0x555a2c58 ) at ../../binutils-gdb/bfd/elf32-hppa.c:2925 #2 0x555a2e07 in gldhppalinux_after_allocation () at ehppalinux.c:354 #3 0x5559af2a in ldemul_after_allocation () at ../../binutils-gdb/ld/ldemul.c:76 #4 0x55590259 in lang_process () at ../../binutils-gdb/ld/ldlang.c:7403 #5 0x5559466e in main (argc=5, argv=0x7fffcd98) at ../../binutils-gdb/ld/ldmain.c:438 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23207] hppa ld SIGSEGVs on invalid object files: bfd/elf32-hppa.c:468 : hppa_get_stub_entry()
https://sourceware.org/bugzilla/show_bug.cgi?id=23207 --- Comment #6 from Sergei Trofimovich --- Created attachment 11034 --> https://sourceware.org/bugzilla/attachment.cgi?id=11034&action=edit bug-orig.o bug-orig.o is an object file produced by gcc on libressl-2.6.4 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22706] bfd/elf32-sh.c fails asserts without additional information: sh4-unknown-linux-gnu-ld: BFD assertion fail bfd/elf32-sh.c:5171
https://sourceware.org/bugzilla/show_bug.cgi?id=22706 --- Comment #2 from Sergei Trofimovich --- I'm afraid I can't reproduce it on current toolchain versions as is (something was fixed): gcc-8.1.0, binutils-2.30, glibc-2.27 I'll try to craft relocations to point to invalid instructions to trigger the same uninformative assertion failures. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22706] bfd/elf32-sh.c fails asserts without additional information: sh4-unknown-linux-gnu-ld: BFD assertion fail bfd/elf32-sh.c:5171
https://sourceware.org/bugzilla/show_bug.cgi?id=22706 --- Comment #4 from Sergei Trofimovich --- Created attachment 11151 --> https://sourceware.org/bugzilla/attachment.cgi?id=11151&action=edit bug.S -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22706] bfd/elf32-sh.c fails asserts without additional information: sh4-unknown-linux-gnu-ld: BFD assertion fail bfd/elf32-sh.c:5171
https://sourceware.org/bugzilla/show_bug.cgi?id=22706 --- Comment #3 from Sergei Trofimovich --- Created attachment 11150 --> https://sourceware.org/bugzilla/attachment.cgi?id=11150&action=edit binutils-gdb-sh4-better-errors.patch -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22706] bfd/elf32-sh.c fails asserts without additional information: sh4-unknown-linux-gnu-ld: BFD assertion fail bfd/elf32-sh.c:5171
https://sourceware.org/bugzilla/show_bug.cgi?id=22706 --- Comment #5 from Sergei Trofimovich --- Managed to craft an object file to trigger needed asserts. As a bonus the test also causes out-of-bounds read access in ld and causes SIGSEGV: # cat bug.S # trying to trigger BFD_ASSERTs to make errors better: # https://sourceware.org/PR22706 # originally was found on toolchain that hits those asserts # and makes failures hard to discover .text .globl _start _start: .word 0 .word 0 .word 0 .globl bar .hidden bar bar: .word 0 .word 0 .word 0 .reloc _start, R_SH_TLS_LE_32, bar-5 .reloc _start, R_SH_TLS_IE_32, bar-5 .reloc _start, R_SH_TLS_GD_32, bar-5 Triggering (already patched binutils to produce nicer failures): $ sh4-unknown-linux-gnu-as bug.S -o bug.o $ sh4-unknown-linux-gnu-ld -m shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o bug.elf bug.o sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5156 sh4-unknown-linux-gnu-ld: bug.o(.text+0xfff6): unexpected instruction (expected 0xd0??, mov.l) sh4-unknown-linux-gnu-ld: bug.o(.text+0xfff8): unexpected instruction 0021 (expected 0x0?12, stc) sh4-unknown-linux-gnu-ld: bug.o(.text+0xfffa): unexpected instruction (expected 0x0?ce, mov.l) sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5115 sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5126 sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5128 sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5130 sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5132 sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5134 sh4-unknown-linux-gnu-ld: BFD (Gentoo 2.30 p3) 2.30.0 assertion fail /tmp/portage-tmpdir/portage/cross-sh4-unknown-linux-gnu/binutils-2.30-r3/work/binutils-2.30/bfd/elf32-sh.c:5136 free(): invalid size ./do.sh: line 7: 17526 Aborted (core dumped) sh4-unknown-linux-gnu-ld -m shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o bug.elf bug.o valgrind suggests SIGSEGV might be related to out-of-bounds write: ==22276== Invalid read of size 2 ==22276==at 0x4E790A0: bfd_getl16 (libbfd.c:505) ==22276==by 0x4E91634: sh_elf_relocate_section (elf32-sh.c:5159) ==22276==by 0x4EB870F: elf_link_input_bfd (elflink.c:10715) ==22276==by 0x4EBA25E: bfd_elf_final_link (elflink.c:12033) ==22276==by 0x1294CE: ldwrite (ldwrite.c:581) ==22276==by 0x11202F: main (ldmain.c:456) ==22276== Address 0x596b806 is 10 bytes before a block of size 12 alloc'd ==22276==at 0x4C2CE6F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==22276==by 0x4E78E81: bfd_malloc (libbfd.c:193) ==22276==by 0x4EB9DE0: bfd_elf_final_link (elflink.c:11910) ==22276==by 0x1294CE: ldwrite (ldwrite.c:581) ==22276==by 0x11202F: main (ldmain.c:456) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23527] New: regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527 Bug ID: 23527 Summary: regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Created attachment 11183 --> https://sourceware.org/bugzilla/attachment.cgi?id=11183&action=edit binutils-protected-663442.tar.gz The report is extracted from chromium link failure: https://bugs.gentoo.org/663442 Minimal example: $ cat a.s .text .globl a .type a, @function .protected a a: ud2 $ cat b.s .text .globl a .type a, @function .protected a .globl b .type b, @function .protected b b: jmp a $ cat a.sh #!/bin/bash for cc in gcc clang; do echo "cc=$cc" $cc -O2 -fPIC -c a.s -o a.$cc.o $cc -O2 -fPIC -c b.s -o b.$cc.o #objdump -d -r a.o b.o ld -shared \ -fPIC \ -o lib.$cc.so \ a.$cc.o b.$cc.o "$@" done $ LANG=C ./a.sh cc=gcc cc=clang ld: b.clang.o: relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object ld: final link failed: bad value Note: clang builds slightly different final binary using non-PLT reference: $ diffoscope b.gcc.o b.clang.o -0001 00040004 R_X86_64_PLT32 a - 4 +0001 00010002 R_X86_64_PC32 a - 4 Both tests pass on binutils-2.30 and fail on binutils-2.31.1 (for object files built by clang). binutils-master also fails: $ LANG=C ~/dev/git/binutils-gdb-native/ld/ld-new -shared -fPIC -o lib.clang.so a.clang.o b.clang.o /home/slyfox/dev/git/binutils-gdb-native/ld/ld-new: b.clang.o: relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object /home/slyfox/dev/git/binutils-gdb-native/ld/ld-new: final link failed: bad value Attaching final binaries. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527 --- Comment #1 from Sergei Trofimovich --- Binutils target is x86_64-pc-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527 Sergei Trofimovich changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Sergei Trofimovich --- Bisected the change to: bd7ab16b4537788ad53521c45469a1bdae84ad4a is the first bad commit commit bd7ab16b4537788ad53521c45469a1bdae84ad4a Author: H.J. Lu Date: Tue Feb 13 07:34:22 2018 -0800 x86-64: Generate branch with PLT32 relocation Since there is no need to prepare for PLT branch on x86-64, generate R_X86_64_PLT32, instead of R_X86_64_PC32, if possible, which can be used as a marker for 32-bit PC-relative branches. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527
Sergei Trofimovich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Sergei Trofimovich ---
Thank you! Looks like newest clang already adopted the change.
Closing as INVALID. I'll try to find exact llvm commit that fixed it.
$ cat a.c
void a(void) __attribute__((visibility("protected")));
void a(void){}
$ cat b.c
void a(void) __attribute__((visibility("protected")));
void b(void) __attribute__((visibility("protected")));
void b(void) { a(); }
$ cat a.sh
#!/bin/bash
for cc in gcc clang-8 clang-6.0; do
echo "cc=$cc"
$cc -O2 -fPIC -c a.c -o a.$cc.o
$cc -O2 -fPIC -c b.c -o b.$cc.o
#objdump -d -r a.o b.o
ld -shared \
-fPIC \
-o lib.$cc.so \
a.$cc.o b.$cc.o "$@"
done
$ LANG=C ./a.sh
cc=gcc
cc=clang-8
cc=clang-6.0
ld: b.clang-6.0.o: relocation R_X86_64_PC32 against protected symbol `a' can
not be used when making a shared object
ld: final link failed: bad value
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23527] regression (ld-2.30 worked): relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23527 --- Comment #5 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #4) > I'll try to find exact llvm commit that fixed it. Found it: commit 930bcc9bdfb9542a292c3de874d7e6ba1464cfe0 Author: George Rimar Date: Tue Feb 20 10:17:57 2018 + [llvm-mc] - Produce R_X86_64_PLT32 for "call/jmp foo". For instructions like call foo and jmp foo patch changes relocation produced from R_X86_64_PC32 to R_X86_64_PLT32. Relocation can be used as a marker for 32-bit PC-relative branches. Linker will reduce PLT32 relocation to PC32 if function is defined locally. Differential revision: https://reviews.llvm.org/D43383 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23534] ld.bfd: internal error from ldlang.c:6635
https://sourceware.org/bugzilla/show_bug.cgi?id=23534 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #7 from Sergei Trofimovich --- I had a look at it in https://bugs.gentoo.org/663690#c19 TL;DR: Gentoo has two libbfd-2.30.0.so libraries with incompatible ABIs: /usr/lib/binutils/i686-pc-linux-gnu/2.30/libbfd-2.30.0.so and /usr/lib/libbfd-2.30.0.so One of them is built --enable-64-bit-bfd, then other is not. Unfortunately the have the same SONAME and the error is subtle. Normally it's not al issue as 'ld' uses private library at /usr/lib/binutils/i686-pc-linux-gnu/2.30/libbfd-2.30.0.so Unfortunately cargo(rust?) uses LD_LIBRARY_PATH=/usr/lib environment when calls gcc/ld and tricks ld into loading wrong (ABI-incompatible) library. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23534] ld.bfd: internal error from ldlang.c:6635
https://sourceware.org/bugzilla/show_bug.cgi?id=23534 --- Comment #9 from Sergei Trofimovich --- (In reply to Alan Modra from comment #8) > > Gentoo has two libbfd-2.30.0.so libraries with incompatible ABIs: > > One of them is built --enable-64-bit-bfd, then other is not > > Ouch, that would explain this bug. All sorts of mayhem would ensue. It's a > wonder that ld didn't segfault immediately. Would it be sensible to request binutils libraries to expand SONAME to include the bits that influence ABI? For example to change libbfd.so -> libbfd-2.30.0.so to something like libbfd.so -> libbfd-2.30.0-64-bit-bfd.so That way when user rebuilds binutils with different flags they would get the errors about missing library instead of obscure SIGSEGV. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23271] internal error ../../ld/ldlang.c 6643
https://sourceware.org/bugzilla/show_bug.cgi?id=23271 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #3 from Sergei Trofimovich --- Could it be the issue similar to https://sourceware.org/bugzilla/show_bug.cgi?id=23534#c7 ? Where libbfd.so changed for some reason and 'ld' binary was not rebuilt against it. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23653] New: ld SIGSEGVs when attempts to link sparc object with x86_64 library (--enable-targets=all): assertion fail ../../binutils-gdb/bfd/elfxx-sparc.c:1218
https://sourceware.org/bugzilla/show_bug.cgi?id=23653
Bug ID: 23653
Summary: ld SIGSEGVs when attempts to link sparc object with
x86_64 library (--enable-targets=all): assertion fail
../../binutils-gdb/bfd/elfxx-sparc.c:1218
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 11245
--> https://sourceware.org/bugzilla/attachment.cgi?id=11245&action=edit
binutils-multitarget-sparc.tar.gz
Original failure was discovered when cross-compiling lua: build system
accidentally linked sparc objects into x86_64 libc:
$ ${HOME}/dev/git/binutils-gdb-native-all-targets/ld/ld-new --eh-frame-hdr
-m elf_x86_64 -shared -o bug.so.5 bug.o ./libc.so.6 ./crtendS.o
/home/slyfox/dev/git/binutils-gdb-native-all-targets/ld/ld-new: BFD (GNU
Binutils) 2.31.51.20180913 assertion fail
../../binutils-gdb/bfd/elfxx-sparc.c:1218
Segmentation fault (core dumped)
Built binutils from master as:
$ ../binutils-gdb/configure --enable-targets=all --disable-werror
Object files are attached. Note: only bug.o is a sparc object.
$ file bug.o ./libc.so.6 ./crtendS.o
bug.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped
./libc.so.6: ELF 64-bit LSB pie executable x86-64, version 1 (GNU/Linux),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
3.2.0, stripped
./crtendS.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23653] ld SIGSEGVs when attempts to link sparc object with x86_64 library (--enable-targets=all): assertion fail ../../binutils-gdb/bfd/elfxx-sparc.c:1218
https://sourceware.org/bugzilla/show_bug.cgi?id=23653
Sergei Trofimovich changed:
What|Removed |Added
Target||sparc-*
Host||x86_64-*
Build||x86_64-*
--- Comment #1 from Sergei Trofimovich ---
Sometimes the crash happens before an assert.
valgrind reports the following first erroneous dereference:
==8230== Invalid read of size 4
==8230==at 0x8F116A: _bfd_sparc_elf_create_dynamic_sections
(elfxx-sparc.c:1223)
==8230==by 0x6922DF: _bfd_elf_link_create_dynamic_sections (elflink.c:362)
==8230==by 0x695401: elf_add_dt_needed_tag (elflink.c:3532)
==8230==by 0x697DAE: elf_link_add_object_symbols (elflink.c:4208)
==8230==by 0x697DAE: bfd_elf_link_add_symbols (elflink.c:5723)
==8230==by 0x2CD740: load_symbols (ldlang.c:2881)
==8230==by 0x2CE184: open_input_bfds (ldlang.c:3330)
==8230==by 0x2D0410: lang_process (ldlang.c:7182)
==8230==by 0x2BE3C6: main (ldmain.c:438)
Which is:
bfd_boolean
_bfd_sparc_elf_create_dynamic_sections (bfd *dynobj,
struct bfd_link_info *info)
{
struct _bfd_sparc_elf_link_hash_table *htab;
htab = _bfd_sparc_elf_hash_table (info);
/*1218:*/ BFD_ASSERT (htab != NULL);
if (!_bfd_elf_create_dynamic_sections (dynobj, info))
return FALSE;
/*1223:*/ if (htab->is_vxworks)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23817] New: strip corrupts SHT_LLVM_ADDRSIG section (files built with clang-7)
https://sourceware.org/bugzilla/show_bug.cgi?id=23817
Bug ID: 23817
Summary: strip corrupts SHT_LLVM_ADDRSIG section (files built
with clang-7)
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 11364
--> https://sourceware.org/bugzilla/attachment.cgi?id=11364&action=edit
t.tar.gz
Issue originally discovered in https://bugs.gentoo.org/667854 as a menacing
warning on x86_64 and arm64:
$ echo 'void f(void){}' > a.c
$ clang -c a.c -o a.o.clang
$ cp a.o.clang a.o
$ strip a.o
strip: stTEWJ8A: failed to find link section for section 5
strip: stTEWJ8A: failed to find link section for section 5
$ sha1sum a.o.clang a.o
34c07c978aeb3ef1fbe2083b5fbaf608c7fe63ec a.o.clang
2060df629d6b818cb1c56147dc9c89cfd5fbf5ad a.o
The warning comes from .llvm_addrsig (SHT_LLVM_ADDRSIG) and attached
strtab/symtab. strip strips unreferenced symbols but does not touch
.llvm_addrsig rendering references invalid (I think).
https://reviews.llvm.org/D47744 has SHT_LLVM_ADDRSIG description.
I'm not sure what exactly binutils (or llvm) should do here. A few options:
1. avoid stripping binaries with unknown unhandled sections
2. Add support for SHT_LLVM_ADDRSIG handling
3. Come back to llvm and add some generic relocations(?) into .llvm_addrsig if
possible so binutiols' strip would just work.
Attaching t.tar.gz with a.c a.o a.o.clang
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23892] New: ld.gold fails partial linking on sparc64 for global registers: only registers %g[2367] can be declared using STT_REGISTER
https://sourceware.org/bugzilla/show_bug.cgi?id=23892
Bug ID: 23892
Summary: ld.gold fails partial linking on sparc64 for global
registers: only registers %g[2367] can be declared
using STT_REGISTER
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: slyfox at inbox dot ru
CC: ian at airs dot com
Target Milestone: ---
Initially observed as a build failure of linux kernel:
make defconfig
make LD=sparc64-unknown-linux-gnu-ld.gold
...
sparc64-unknown-linux-gnu-ld.gold: error: drivers/char/hw_random/core.o:
only registers %g[2367] can be declared using STT_REGISTER
Here is the minimal reproducer:
$ cat bug.c
register long a asm("g6");
$ sparc64-unknown-linux-gnu-gcc -Wall -c -o bug0.o bug.c
$ sparc64-unknown-linux-gnu-ld.gold -m elf64_sparc -r -o bug1-gold.o bug0.o
$ sparc64-unknown-linux-gnu-ld.gold -m elf64_sparc -r -o bug2-gold.o
bug1-gold.o
$ sparc64-unknown-linux-gnu-ld.gold: error: bug1-gold.o: only registers
%g[2367] can be declared using STT_REGISTER
Note, partial linking is very simple here as it uses single input source.
Second partial linking step should be a no-op (it is a no-op on bfd).
Attached source and emitted binaries.
Tool versions:
binutils: 2.31.1
gcc: 8.2.0
target: sparc64-unknown-linux-gnu
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23892] ld.gold fails partial linking on sparc64 for global registers: only registers %g[2367] can be declared using STT_REGISTER
https://sourceware.org/bugzilla/show_bug.cgi?id=23892 --- Comment #1 from Sergei Trofimovich --- Created attachment 11400 --> https://sourceware.org/bugzilla/attachment.cgi?id=11400&action=edit bug.tar.gz -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23892] ld.gold fails partial linking on sparc64 for global registers: only registers %g[2367] can be declared using STT_REGISTER
https://sourceware.org/bugzilla/show_bug.cgi?id=23892 --- Comment #2 from Sergei Trofimovich --- Diffing 'objdump -x bug1-bfd.o' and 'objdump -x bug1-gold.o' shows that register number is changed: bfd: REG_G6 g R *UND* a gold: REG_G4 g R *UND* a -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21518] ld.gold should ignore -pie flag for --oformat=binary mode (ld.bfd does)
https://sourceware.org/bugzilla/show_bug.cgi?id=21518 Sergei Trofimovich changed: What|Removed |Added Summary|ld.gold should ignmore -pie |ld.gold should ignore -pie |flag for --oformat=binary |flag for --oformat=binary |mode (ld.bfd does) |mode (ld.bfd does) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23958] New: -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://sourceware.org/bugzilla/show_bug.cgi?id=23958
Bug ID: 23958
Summary: -flto -Wl,--whole-archive causes "multiple definition"
errors in elfutils (only for bfd, not gold)
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 11435
--> https://sourceware.org/bugzilla/attachment.cgi?id=11435&action=edit
gcc-lto-616038.tar.gz
Original example is a build failure of elfutils-0.175 against CFLAGS=-flto at:
https://bugs.gentoo.org/616038
In case it's a gcc bug I also files:
https://gcc.gnu.org/PR88396
Angrew suspects it might be related to
https://sourceware.org/PR12319
Extracted minimal reproducer looks like that:
$ cat libdw.map
ELFUTILS_0.143 {
global:
dwarf_bytesize;
};
$ cat dwarf_bytesize.os.c
void dwarf_bytesize (void) {}
asm (".symver dwarf_bytesize,dwarf_bytesize@@@ELFUTILS_0.143");
Reproducer:
$ gcc -flto -c dwarf_bytesize.os.c -o dwarf_bytesize.os -fPIC
$ gcc-ar cr libdw_pic.a dwarf_bytesize.os
$ gcc-ranlib libdw_pic.a
$ gcc -flto -o libdw.so -shared -Wl,--version-script,libdw.map,--no-undefined
-Wl,--whole-archive libdw_pic.a -Wl,--no-whole-archive -fuse-ld=bfd
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd:
/tmp/ccYR58eH.ltrans0.ltrans.o:(*IND*+0x0): multiple definition of
`dwarf_bytesize'; dwarf_bytesize.os (symbol from plugin):(.text+0x0): first
defined here
Using binutils-2.31.1 / gcc-8.2.0 here.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/tmp/portage-tmpdir/portage/sys-devel/gcc-8.2.0-r5/work/gcc-8.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 8.2.0-r5 p1.6' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--enable-vtable-verify --enable-libvtv --enable-lto --with-isl
--disable-isl-version-check --enable-libsanitizer --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 8.2.0 (Gentoo 8.2.0-r5 p1.6)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23968] New: GOTPCREL(%rip) references against .local symbols generate invalid code in -mrelax-relocations=no mode (chromium build crashes)
https://sourceware.org/bugzilla/show_bug.cgi?id=23968
Bug ID: 23968
Summary: GOTPCREL(%rip) references against .local symbols
generate invalid code in -mrelax-relocations=no mode
(chromium build crashes)
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
sultan on freenode/#gentoo-toolchain reported a chromium build failure when
CFLAGS=-Wa,-mrelax-relocations=no is used. sultan uses it to have whole system
compatible with old binutils without R_X86_64_REX_GOTPCRELX support.
I expored a failure a bit and am not sure if it's a chromium bug or
binutils/gas bug. I'm leaning towards binutils/gas. Here is the minimal
single-file example:
typedef unsigned char u8;
/*
extracted from
chromium-71.0.3578.80/work/chromium-71.0.3578.80/out/Release/gen/v8/embedded.cc
# --enable-x86-relax-relocations
$ x86_64-pc-linux-gnu-g++ -fPIC -O0 -Wa,-mrelax-relocations=yes a-yes.o -o
a-yes
$ ./a-yes
42 # works
# --disable-x86-relax-relocations
$ x86_64-pc-linux-gnu-g++ -fPIC -O0 -Wa,-mrelax-relocations=no a-no.o -o
a-no
$ ./a-no
# fails
*/
namespace {
__asm__(
".section .text\n"
".local v8_Default_embedded_blob_\n"
//This would work:
//".global v8_Default_embedded_blob_\n"
//".hidden v8_Default_embedded_blob_\n"
"v8_Default_embedded_blob_:\n"
// some raw injected data
".byte 0x42\n"
);
extern "C" const u8 v8_Default_embedded_blob_[];
}
const u8* DefaultEmbeddedBlob(void) {
// generates reference
//movqv8_Default_embedded_blob_@GOTPCREL(%rip), %rax
// is it valid for .local symbols?
// If it's invalid should it be forbidden by gas? If it's valid
// should it always generate a reloc here?
return v8_Default_embedded_blob_;
}
// test main.c:
#include
int main() {
printf ("b0=%02X\n", DefaultEmbeddedBlob()[0]);
}
The culprit here is in a mix of .local / @GOTPCREL(%rip) references.
It works for -mrelax-relocations=yes but does not for -mrelax-relocations=no.
Can binutils do the same thing in both cases? I would suggest:
- either generate relocation in both cases
- or forbid @GOTPCREL references against .local symbols and fail the assembly
Investigation notes:
Assembly file is the same in both cases. Object file difference is the
following:
$ x86_64-pc-linux-gnu-g++ -fPIC -O0 -Wa,-mrelax-relocations=no -c
embedded.o.cc -o a-no.o
$ x86_64-pc-linux-gnu-g++ -fPIC -O0 -Wa,-mrelax-relocations=yes -c
embedded.o.cc -o a-yes.o
$ objdump -d -r a-no.o > a-no.od
$ objdump -d -r a-yes.o > a-yes.od
$ diff -u a-no.od a-yes.od
Disassembly of section .text:
@@ -10,7 +10,8 @@
0001 <_Z19DefaultEmbeddedBlobv>:
1: 55 push %rbp
2: 48 89 e5mov%rsp,%rbp
- 5: 48 8b 05 f4 ff ff ffmov-0xc(%rip),%rax# 0
+ 5: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# c
<_Z19DefaultEmbeddedBlobv+0xb>
+ 8: R_X86_64_REX_GOTPCRELX
v8_Default_embedded_blob_-0x4
c: 5d pop%rbp
d: c3 retq
Here 'no' case has extra memory dereference as if '-0xc(%rip)' would be a GOT
entry for v8_Default_embedded_blob_. Or 'mov' was used by accident instead of
'lea'.
Final binary change:
$ x86_64-pc-linux-gnu-g++ -fPIC -O0 -Wa,-mrelax-relocations=no a-no.o -o
a-no
$ x86_64-pc-linux-gnu-g++ -fPIC -O0 -Wa,-mrelax-relocations=yes a-yes.o -o
a-yes
$ objdump -d -R a-no > a-no.od
$ objdump -d -R a-yes > a-yes.od
$ diff -u a-no.od a-yes.od
Disassembly of section .init:
@@ -115,7 +115,7 @@
064b <_Z19DefaultEmbeddedBlobv>:
64b: 55 push %rbp
64c: 48 89 e5mov%rsp,%rbp
- 64f: 48 8b 05 f4 ff ff ffmov-0xc(%rip),%rax# 64a
+ 64f: 48 8d 05 f4 ff ff fflea-0xc(%rip),%rax# 64a
656: 5d pop%rbp
657: c3 retq
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23968] GOTPCREL(%rip) references against .local symbols generate invalid code in -mrelax-relocations=no mode (chromium build crashes)
https://sourceware.org/bugzilla/show_bug.cgi?id=23968 Sergei Trofimovich changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23968] GOTPCREL(%rip) references against .local symbols generate invalid code in -mrelax-relocations=no mode (chromium build crashes)
https://sourceware.org/bugzilla/show_bug.cgi?id=23968 Sergei Trofimovich changed: What|Removed |Added CC||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24225] New: nios2 overflows stack with error message: *** buffer overflow detected ***: /usr/libexec/gcc/nios2-unknown-linux-gnu/ld terminated
https://sourceware.org/bugzilla/show_bug.cgi?id=24225 Bug ID: 24225 Summary: nios2 overflows stack with error message: *** buffer overflow detected ***: /usr/libexec/gcc/nios2-unknown-linux-gnu/ld terminated Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- When linking a huge program (GHC) ld attempted to localize format string and crashed as: gdb --quiet /usr/libexec/gcc/nios2-unknown-linux-gnu/ld ./core.24349 Reading symbols from /usr/libexec/gcc/nios2-unknown-linux-gnu/ld...Reading symbols from /usr/lib64/debug//usr/x86_64-pc-linux-gnu/nios2-unknown-linux-gnu/binutils-bin/2.32/ld.bfd.debug...done. done. [New LWP 24349] Core was generated by `/usr/libexec/gcc/nios2-unknown-linux-gnu/ld @/tmp/ccBN1CqS'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50return ret; (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f26670fc535 in __GI_abort () at abort.c:79 #2 0x7f2667158c59 in __libc_message (action=, fmt=fmt@entry=0x7f2667270133 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x7f26671f3715 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7f26672700bf "buffer overflow detected") at fortify_fail.c:28 #4 0x7f26671f3751 in __GI___fortify_fail (msg=msg@entry=0x7f26672700bf "buffer overflow detected") at fortify_fail.c:44 #5 0x7f26671f1880 in __GI___chk_fail () at chk_fail.c:28 #6 0x7f266714ff79 in _IO_str_chk_overflow (fp=, c=) at iovsprintf.c:35 #7 0x7f266715db61 in __GI__IO_default_xsputn (f=0x7fff951a2870, data=, n=81) at libioP.h:904 #8 0x7f2667142f42 in __vfprintf_internal (s=s@entry=0x7fff951a2870, format=format@entry=0x7f26672f9ee4 , ap=ap@entry=0x7fff951a29b0, mode_flags=mode_flags@entry=6) at ../libio/libioP.h:904 #9 0x7f2667150021 in __vsprintf_internal ( string=0x7fff951a2ba0 "невозможно достичь base_DataziData_CharRep_closure (по адресу 0x02fc1970) из глобального указателя (по адресу 0x02fb8c10), так как смещ"..., maxlen=maxlen@entry=256, format=0x7f26672f9ee4 , args=args@entry=0x7fff951a29b0, mode_flags=mode_flags@entry=6) at iovsprintf.c:96 #10 0x7f26671f128e in ___sprintf_chk ( s=s@entry=0x7fff951a2ba0 "невозможно достичь base_DataziData_CharRep_closure (по адресу 0x02fc1970) из глобального указателя (по адресу 0x02fb8c10), так как смещ"..., flag=flag@entry=1, slen=slen@entry=256, format=) at sprintf_chk.c:40 #11 0x7f266736c004 in sprintf (__fmt=, __s=0x7fff951a2ba0 "невозможно достичь base_DataziData_CharRep_closure (по адресу 0x02fc1970) из глобального указателя (по адресу 0x02fb8c10), так как смещ"...) at /usr/include/bits/stdio2.h:36 #12 nios2_elf32_relocate_section (output_bfd=output_bfd@entry=0x5624f9e62be0, info=0x5624f92f9a60 , input_bfd=input_bfd@entry=0x5624fc14f7c0, input_section=input_section@entry=0x5624fc1e13e0, contents=0x5625014d1d00 "\004\376\377\336\025\001", relocs=relocs@entry=0x7f2658973020, local_syms=0x562500832e90, local_sections=0x5625022f3dc0) at ../../binutils-2.32/bfd/elf32-nios2.c:3846 #13 0x7f26673947a0 in elf_link_input_bfd (flinfo=flinfo@entry=0x7fff951a2f60, input_bfd=input_bfd@entry=0x5624fc14f7c0) at ../../binutils-2.32/bfd/elflink.c:10856 #14 0x7f26673962bf in bfd_elf_final_link (abfd=, info=) at ../../binutils-2.32/bfd/elflink.c:12183 #15 0x5624f9294e2f in ldwrite () at ../../binutils-2.32/ld/ldwrite.c:581 #16 0x5624f927d410 in main (argc=, argv=) at ../../binutils-2.32/ld/ldmain.c:464 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24225] nios2 overflows stack with error message: *** buffer overflow detected ***: /usr/libexec/gcc/nios2-unknown-linux-gnu/ld terminated
https://sourceware.org/bugzilla/show_bug.cgi?id=24225
--- Comment #1 from Sergei Trofimovich ---
I think the problem here happens at bfd/elf32-nios2.c:3846:
static bfd_boolean nios2_elf32_relocate_section (bfd *output_bfd, ...) {
...
char msgbuf[256];
...
/* xgettext:c-format */
format = _("unable to reach %s (at 0x%08x) from the "
"global pointer (at 0x%08x) because the "
"offset (%d) is out of the allowed range, "
"-32678 to 32767\n" );
sprintf (msgbuf, format, name, symbol_address, gp,
(signed)relocation);
snprintf() does out-of-bound write due to relatively long symbol name and big
blowup of format string in 'ru' locale.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24225] nios2 overflows stack with error message: *** buffer overflow detected ***: /usr/libexec/gcc/nios2-unknown-linux-gnu/ld terminated
https://sourceware.org/bugzilla/show_bug.cgi?id=24225 Sergei Trofimovich changed: What|Removed |Added Target||nios2-* -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/25316] New: ia64 ld fails to convert binary into elf: "failed to merge target specific data"
https://sourceware.org/bugzilla/show_bug.cgi?id=25316 Bug ID: 25316 Summary: ia64 ld fails to convert binary into elf: "failed to merge target specific data" Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Bug originally reported at https://bugs.gentoo.org/699180 by Émeric Maschino. Small reproducer: $ echo hi > hello.123 $ ia64-unknown-linux-gnu-ld -r -b binary hello.123 -o hello.o ia64-unknown-linux-gnu-ld: failed to merge target specific data of file hello.123 $ ia64-unknown-linux-gnu-ld -r -b binary hello.123 -o hello.o --no-warn-mismatch It works without problems on other targets. AFAIU glibc's inlent is to: 1. convert arbitrary binary into an ELF file 2. assign a symbol to it 3. refer from other source files It's a step 1 that fails. The target is ia64-unknown-linux-gnu. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25316] ia64 ld fails to convert binary into elf: "failed to merge target specific data"
https://sourceware.org/bugzilla/show_bug.cgi?id=25316
--- Comment #1 from Sergei Trofimovich ---
AFAIU eary failure happens at input checking against ELF:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elfnn-ia64.c;h=459d986c0350f5e5982c7738ea69273f2ae97f7a;hb=HEAD#l4744
4735 static bfd_boolean
4736 elfNN_ia64_merge_private_bfd_data (bfd *ibfd, struct bfd_link_info *info)
4737 {
...
4743 /* Don't even pretend to support mixed-format linking. */
4744 if (bfd_get_flavour (ibfd) != bfd_target_elf_flavour
...
4746 return FALSE;
Looks like many other targets have that check but see to work. Does ia64 port
miss some earlier step to convert binary into an ELF?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25316] ia64 ld fails to convert binary into elf: "failed to merge target specific data"
https://sourceware.org/bugzilla/show_bug.cgi?id=25316 --- Comment #2 from Sergei Trofimovich --- Created attachment 12147 --> https://sourceware.org/bugzilla/attachment.cgi?id=12147&action=edit binutils-2.32-ia64-allow-binary-merge.patch It looks like other targets (like mips and riscv64) just skip _private hook entirely. I did the same and got something that looks like an ia64 ELF. Will test a bit. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25316] ia64 ld fails to convert binary into elf: "failed to merge target specific data"
https://sourceware.org/bugzilla/show_bug.cgi?id=25316 --- Comment #3 from Sergei Trofimovich --- Sent for review as https://sourceware.org/ml/binutils/2019-12/msg00340.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25331] New: mmix-gas fals to assemble newlib-3.1.0 (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag
https://sourceware.org/bugzilla/show_bug.cgi?id=25331 Bug ID: 25331 Summary: mmix-gas fals to assemble newlib-3.1.0 (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag Product: binutils Version: 2.33 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Created attachment 12160 --> https://sourceware.org/bugzilla/attachment.cgi?id=12160&action=edit min-bug.c It's a copy of https://gcc.gnu.org/PR93108 ticket (new-lib-3.1.0 fais to build with -fstack-protector-strong). Hans-Peter Nilsson suggested it's a binutils bug. I'm assuming it's a gas bug as it generates the error message. Reproducible on binutils-2.33.1 and gcc-9.2.0 (and gcc-master) as: $ ./xgcc -B. -fstack-protector-strong -c min-bug.c -o min-bug.o -save-temps min-bug.c: Assembler messages: min-bug.c:430: Error: internal error: fixup not contained within frag -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25331] mmix-gas fals to assemble newlib-3.1.0 (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag
https://sourceware.org/bugzilla/show_bug.cgi?id=25331 --- Comment #1 from Sergei Trofimovich --- Created attachment 12161 --> https://sourceware.org/bugzilla/attachment.cgi?id=12161&action=edit min-bug.s min-bug.s was generated by -save-temps. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25331] mmix-gas fals to assemble newlib-3.1.0 (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag
https://sourceware.org/bugzilla/show_bug.cgi?id=25331 Sergei Trofimovich changed: What|Removed |Added Target||mmix-* CC||hp at bitrange dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25316] ia64 ld fails to convert binary into elf: "failed to merge target specific data"
https://sourceware.org/bugzilla/show_bug.cgi?id=25316 --- Comment #4 from Sergei Trofimovich --- Was pushed as https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=b26a3d5827edcb942b3af5b921bf317bbc0c8e83 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru, ||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #13 from Sergei Trofimovich ---
(In reply to H.J. Lu from comment #12)
> It is independent of -fno-common:
>
>
> [hjl@gnu-cfl-2 pr25355]$ cat x.c
> int nm_test_var = 30;
>
> extern int foo (void);
>
> int
> main ()
> {
> return foo ();
> }
> [hjl@gnu-cfl-2 pr25355]$ gcc -flto -c x.c
> [hjl@gnu-cfl-2 pr25355]$ gcc-nm x.o
> U foo
> T main
> T nm_test_var
> [hjl@gnu-cfl-2 pr25355]$
Which gcc version you test? gcc-10 switched to -fno-common in
https://gcc.gnu.org/PR85678.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25694] New: R_RISCV_TPREL_HI20 relocations cause riscv64 to add TEXTREL bit on executables
https://sourceware.org/bugzilla/show_bug.cgi?id=25694
Bug ID: 25694
Summary: R_RISCV_TPREL_HI20 relocations cause riscv64 to add
TEXTREL bit on executables
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Build: x86_64-pc-linux-gnu
Initial bug is reported as a https://bugs.gentoo.org/713082 where gdb-9.1 was
observed to be complied with TEXTRELs. Here is the minimal reproducer:
// $ cat a.cc
static int a () { return 1; }
static thread_local int (*tlf) () = &a;
int main(void) { return tlf(); }
[sf] /tmp/z:cat a.cc
static int a () { return 1; }
static thread_local int (*tlf) () = &a;
int main(void) { return tlf(); }
$ riscv64-unknown-linux-gnu-g++ a.cc -o a -Wl,-z,text -pie -fPIE
/usr/libexec/gcc/riscv64-unknown-linux-gnu/ld: read-only segment has dynamic
relocations
collect2: error: ld returned 1 exit status
$ riscv64-unknown-linux-gnu-g++ -S a.cc -o a.S -Wl,-z,text -pie -fPIE
$ cat a.S
...
main:
...
lui a5,%tprel_hi(_ZL3tlf)
add a5,a5,tp,%tprel_add(_ZL3tlf)
ld a5,%tprel_lo(_ZL3tlf)(a5)
jalra5
...
I assume it's a binutils deficiency as I see no relocations in read-only
sections:
$ riscv64-unknown-linux-gnu-g++ a.cc -o a -pie -fPIE
/usr/libexec/gcc/riscv64-unknown-linux-gnu/ld: warning: creating a DT_TEXTREL
in object
$ LANG=C objdump -D -R a | egrep 'R_RISC|section ' | egrep -A2 'section '
Disassembly of section .interp:
Disassembly of section .note.ABI-tag:
Disassembly of section .gnu.hash:
Disassembly of section .dynsym:
Disassembly of section .dynstr:
Disassembly of section .gnu.version:
Disassembly of section .gnu.version_r:
Disassembly of section .rela.dyn:
Disassembly of section .rela.plt:
Disassembly of section .plt:
Disassembly of section .text:
Disassembly of section .rodata:
Disassembly of section .eh_frame_hdr:
Disassembly of section .eh_frame:
Disassembly of section .tdata:
1da0: R_RISCV_RELATIVE *ABS*+0x72a
Disassembly of section .preinit_array:
1da8: R_RISCV_RELATIVE *ABS*+0x68e
Disassembly of section .init_array:
1db0: R_RISCV_RELATIVE *ABS*+0x728
Disassembly of section .fini_array:
1db8: R_RISCV_RELATIVE *ABS*+0x6ee
Disassembly of section .dynamic:
Disassembly of section .data:
2000: R_RISCV_RELATIVE *ABS*+0x2000
Disassembly of section .got:
2018: R_RISCV_JUMP_SLOT __libc_start_main@GLIBC_2.27
2020: R_RISCV_JUMP_SLOT __stack_chk_fail@GLIBC_2.27
--
Disassembly of section .bss:
Disassembly of section .comment:
0: R_RISCV_NONE *ABS*
riscv_elf_check_relocs() is probably too conservative at attributing
thread_local relocations in PIEs as TEXTRELs.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25694] R_RISCV_TPREL_HI20 relocations cause riscv64 to add TEXTREL bit on executables
https://sourceware.org/bugzilla/show_bug.cgi?id=25694 Sergei Trofimovich changed: What|Removed |Added CC||palmer at dabbelt dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25694] R_RISCV_TPREL_HI20 relocations cause riscv64 to add TEXTREL bit on executables
https://sourceware.org/bugzilla/show_bug.cgi?id=25694 Sergei Trofimovich changed: What|Removed |Added CC||andrew at sifive dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22263] -fpie -pie generates dynamic relocations in text section
https://sourceware.org/bugzilla/show_bug.cgi?id=22263 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #23 from Sergei Trofimovich --- bug #25694 was reported against riscv64. At a cursory glance seems to be the same link_pic vs. link_executable mismatch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22909] Expand --warn-shared-textrel support to all executables, not only PIC objects
https://sourceware.org/bugzilla/show_bug.cgi?id=22909 --- Comment #3 from Sergei Trofimovich --- Gentoo still has that check enabled. A few days ago it found the problem in riscv64 as bug #25694 (a case of bug #22263). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25694] R_RISCV_TPREL_HI20 relocations cause riscv64 to add TEXTREL bit on executables
https://sourceware.org/bugzilla/show_bug.cgi?id=25694 --- Comment #2 from Sergei Trofimovich --- (In reply to Jim Wilson from comment #1) > I believe this is the same as bug 22263, which added a testcase, so we > already have a ld testsuite failure for it. The problem also shows up in > openembedded builds. Yeah, looks like it's exactly it! Don't know if it should be duped or fixed in this bug. That bug accumulated a lot of fixes which are nice to look at how to fix things but make it hard to track what targets were not fixed yet. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25745] powerpc64-unknown-linux-gnu-ld overflows string buffer in --stats mode
https://sourceware.org/bugzilla/show_bug.cgi?id=25745 Sergei Trofimovich changed: What|Removed |Added Target||powerpc64-unknown-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25745] New: powerpc64-unknown-linux-gnu-ld overflows string buffer in --stats mode
https://sourceware.org/bugzilla/show_bug.cgi?id=25745
Bug ID: 25745
Summary: powerpc64-unknown-linux-gnu-ld overflows string buffer
in --stats mode
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Initially observed the crash when building ncurses-6.2 on powerpc64 using
ru_RU.UTF-8 locale.
$ locale
LANG=ru_RU.UTF-8
...
"""
$ powerpc64-unknown-linux-gnu-ld ... -stats -lc ...
GNU ld (Gentoo 2.34 p1) 2.34.0
...
powerpc64-unknown-linux-gnu-ld: заглушки компоновщика в 2 группах
...
Ошибка сегментирования (стек памяти сброшен на диск)
"""
It's a SIGSEGV. valgrind points it to heap buffer overflow at:
==3864715== Invalid write of size 1
==3864715==at 0x483F046: mempcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3864715==by 0x4AB5707: _IO_default_xsputn (genops.c:386)
==3864715==by 0x4AB5707: _IO_default_xsputn (genops.c:370)
==3864715==by 0x4A9D1EC: __vfprintf_internal (vfprintf-internal.c:1719)
==3864715==by 0x4AA9C0F: __vsprintf_internal (iovsprintf.c:96)
==3864715==by 0x4B3D992: __sprintf_chk (sprintf_chk.c:40)
==3864715==by 0x48B3CCB: sprintf (stdio2.h:36)
==3864715==by 0x48B3CCB: ppc64_elf_build_stubs (elf64-ppc.c:14129)
==3864715==by 0x137988: gldelf64ppc_finish (eelf64ppc.c:618)
==3864715==by 0x12959A: lang_process (ldlang.c:7916)
==3864715==by 0x11561C: main (ldmain.c:452)
An overflow happens on locales where most letters are multibyte (like Russian).
Here is a modern binutils-bfd snippet from
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf64-ppc.c;h=7f7e190ce2b656d31ba1f163010ad924c645;hb=HEAD#l14561
which looks suspicious:
14558 if (stats != NULL)
14559 {
14560 size_t len;
14561 *stats = bfd_malloc (500);
14562 if (*stats == NULL)
14563 return FALSE;
14564
14565 len = sprintf (*stats,
14566 ngettext ("linker stubs in %u group\n",
14567"linker stubs in %u groups\n",
14568stub_sec_count),
14569 stub_sec_count);
14570 sprintf (*stats + len, _(" branch %lu\n"
14571" branch toc adj %lu\n"
14572" branch notoc %lu\n"
14573" branch both%lu\n"
14574" long branch%lu\n"
14575" long toc adj %lu\n"
14576" long notoc %lu\n"
14577" long both %lu\n"
14578" plt call %lu\n"
14579" plt call save %lu\n"
14580" plt call notoc %lu\n"
14581" plt call both %lu\n"
14582" global entry %lu"),
14583htab->stub_count[ppc_stub_long_branch - 1],
14584htab->stub_count[ppc_stub_long_branch_r2off - 1],
14585htab->stub_count[ppc_stub_long_branch_notoc - 1],
14586htab->stub_count[ppc_stub_long_branch_both - 1],
14587htab->stub_count[ppc_stub_plt_branch - 1],
14588htab->stub_count[ppc_stub_plt_branch_r2off - 1],
14589htab->stub_count[ppc_stub_plt_branch_notoc - 1],
14590htab->stub_count[ppc_stub_plt_branch_both - 1],
14591htab->stub_count[ppc_stub_plt_call - 1],
14592htab->stub_count[ppc_stub_plt_call_r2save - 1],
14593htab->stub_count[ppc_stub_plt_call_notoc - 1],
14594htab->stub_count[ppc_stub_plt_call_both - 1],
14595htab->stub_count[ppc_stub_global_entry - 1]);
14596 }
14597 return TRUE;
14598 }
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26236] New: ld on sparc produces R_SPARC_NONE relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=26236 Bug ID: 26236 Summary: ld on sparc produces R_SPARC_NONE relocations Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Target: sparc-unknown-linux-gnu Initially the problem was observed by Rolf Eike Beer on elfutils as https://bugs.gentoo.org/619706. There elutils test suite caught that ld produces R_SPARC_NONE relocations on PIE executables. Attaching small archive with 3 object files hopefully enough to reproduce the problem. """ $ sparc-unknown-linux-gnu-ld -m elf32_sparc -pie -o a crtbeginS.o a.o crtend.o -e main sparc-unknown-linux-gnu-ld: warning: creating a DT_TEXTREL in object $ LANG=C sparc-unknown-linux-gnu-readelf -r a Relocation section '.rela.dyn' at offset 0x1e8 contains 9 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0001205c 0016 R_SPARC_RELATIVE 1205c R_SPARC_NONE 0 R_SPARC_NONE 0 R_SPARC_NONE 0 049c 0109 R_SPARC_HI22 0260 .init + 11f44 04a0 010c R_SPARC_LO10 0260 .init + 11f44 0001200c 0314 R_SPARC_GLOB_DAT __cxa_finalize + 0 00012014 0414 R_SPARC_GLOB_DAT _ITM_registerTMCloneTa + 0 00012018 0514 R_SPARC_GLOB_DAT _ITM_deregisterTMClone + 0 Relocation section '.rela.plt' at offset 0x254 contains 1 entry: Offset InfoTypeSym.Value Sym. Name + Addend 0001204c 0315 R_SPARC_JMP_SLOT __cxa_finalize + 0 """ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26236] ld on sparc produces R_SPARC_NONE relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=26236 --- Comment #1 from Sergei Trofimovich --- Created attachment 12695 --> https://sourceware.org/bugzilla/attachment.cgi?id=12695&action=edit binutils-R_SPARC_NONE-reloc.tar.gz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26236] ld on sparc produces R_SPARC_NONE relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=26236 --- Comment #2 from Sergei Trofimovich --- File gcc-specific bug at mixing crtbeginS.o / srtend.o as: https://gcc.gnu.org/PR96190. But after it's fixed I think ld should not generate R_SPARC_NONE relocations for such inputs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26762] New: -Wl, --as-needed removes strong symbols in favour of weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26762
Bug ID: 26762
Summary: -Wl,--as-needed removes strong symbols in favour of
weak symbols
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
CC: ccoutant at gmail dot com
Target Milestone: ---
Original bug was a failed attempt to build llvm-11 with LDFLAGS="-flto
-Wl,--as-needed": https://bugs.gentoo.org/749162.
There std::call_once is implemented via weak pthread_once() symbol:
https://gcc.gnu.org/PR55394. Presence of -Wl,--as-needed removes libpthread.so
and breaks the program at runtime as pthread_once() has to have a real
implementation. gcc plans to fix std::call_once by avoiding pthread_once() for
unrelated reason (solving it will take a while).
But the problem seems to be more general when local weak symbols are used to
probe presence of a real implementation dynamically.
What do you think of changing 'ld' to prefer strong symbols from shared
libraries and keeping DT_NEEDED entries even if local object files define weak
symbols?
Toy example:
$ cat a.c
// gcc a.c -o a -Wl,--as-needed -pthread && ./a
#include
#include
static pthread_once_t once = PTHREAD_ONCE_INIT;
static __typeof(pthread_once) __gthrw_pthread_once __attribute__
((__weakref__("pthread_once"), __copy__ (pthread_once)));
static void ir(void)
{
printf("foo\n");
}
int main(void)
{
if (__gthrw_pthread_once)
__gthrw_pthread_once(&once, &ir);
}
$ gcc a.c -o a -Wl,--as-needed -pthread -fuse-ld=bfd && ./a
$ gcc a.c -o a -Wl,--as-needed -pthread -fuse-ld=gold && ./a
$ gcc a.c -o a -Wl,--as-needed -pthread -fuse-ld=lld && ./a
$ gcc a.c -o a -Wl,--no-as-needed -pthread -fuse-ld=bfd && ./a
foo
Ideally all 4 tests should call pthread_once from libpthread.so.0 instead of
calling local weak reference.
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26762] -Wl,--as-needed removes strong symbols in favour of weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26762 --- Comment #2 from Sergei Trofimovich --- Aha, we'll try to find another workaround downstream then. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26882] New: --enable-textrel-check=warning exposes a few test failures on powerpc and others
https://sourceware.org/bugzilla/show_bug.cgi?id=26882 Bug ID: 26882 Summary: --enable-textrel-check=warning exposes a few test failures on powerpc and others Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- It's a forward of test failures observed downstream https://bugs.gentoo.org/754246 by ernsteiswuerfel. Here is a reproducer: $ ../binutils-gdb/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc-unknown-linux-gnu --enable-textrel-check=warning $ make $ make -C ld check RUNTESTFLAGS='powerpc.exp' Running /home/slyfox/dev/git/binutils-gdb/ld/testsuite/ld-powerpc/powerpc.exp ... FAIL: Reloc section order FAIL: TLS32 shared FAIL: TLS shared FAIL: TLSTOC shared FAIL: ld-powerpc/dotsym3 FAIL: ld-powerpc/dotsym4 FAIL: ld-powerpc/ppc476-shared FAIL: ld-powerpc/ppc476-shared2 Test failures happen because tests have textrels that generate warning on stderr. Here is a 'Reloc section order' example: ld/testsuite/ld-powerpc/reloc.s .section echidna .long .text .section platypus,"ax" .long .text .text b _start@plt nop ld $ ../gas/as-new -o reloc.o -a32 reloc.s ld $ ./ld-new --hash-style=sysv -o reloc.so -z norelro -melf32ppc -shared -z nocombreloc reloc.o ld-new: warning: creating DT_TEXTREL in a shared object I think the TEXTREL warning is correct here and should be ignored by test. Removing '--enable-textrel-check=warning' from ./configure makes all tests pass. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/23607] gold linker --threads --thread-count,2 causes ld segmentation fault
https://sourceware.org/bugzilla/show_bug.cgi?id=23607
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment #7 from Sergei Trofimovich ---
For me the simplest reproducer is the following one-liner:
"""
$ echo 'int main() {}' | x86_64-pc-linux-gnu-gcc -flto -fuse-ld=gold
-Wl,--threads -Wl,--thread-count,32 -x c -
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core
dumped
compilation terminated.
"""
(gcc-master, binutils-2.35.1, x86_64-pc-linux-gnu target)
binutils backtrace:
"""
(gdb) bt
#0 gold::Pluginobj::get_symbol_resolution_info (this=0x7fdc10001010,
symtab=0x7ffe9622ef50, nsyms=, syms=,
version=)
at ../../binutils-2.35.1/gold/plugin.cc:1293
#1 0x7fdc94747c7a in write_resolution () at
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/lto-plugin/lto-plugin.c:569
#2 all_symbols_read_handler () at
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/lto-plugin/lto-plugin.c:749
#3 0x55e7fdf1004f in gold::Plugin::all_symbols_read (this=)
at ../../binutils-2.35.1/gold/plugin.cc:403
#4 gold::Plugin_manager::all_symbols_read (this=0x55e7fe561360,
workqueue=workqueue@entry=0x7ffe9622ec50, task=task@entry=0x55e7fe5bacc0,
input_objects=,
symtab=, dirpath=, mapfile=0x0,
last_blocker=0x55e7fe5bad20) at ../../binutils-2.35.1/gold/plugin.cc:856
#5 0x55e7fdf1018c in gold::Plugin_hook::run (this=0x55e7fe5bacc0,
workqueue=0x7ffe9622ec50) at ../../binutils-2.35.1/gold/plugin.cc:1770
#6 0x55e7fdf6ba70 in gold::Workqueue::find_and_run_task
(this=0x7ffe9622ec50, thread_number=23) at
../../binutils-2.35.1/gold/workqueue.cc:319
#7 0x55e7fdf6bcca in gold::Workqueue::process (this=0x7ffe9622ec50,
thread_number=23) at ../../binutils-2.35.1/gold/workqueue.cc:495
#8 0x55e7fdf6be23 in gold::Workqueue_threader_threadpool::process
(thread_number=, this=) at
../../binutils-2.35.1/gold/workqueue-internal.h:92
#9 gold::Workqueue_thread::thread_body (arg=0x55e7fe5b97d0) at
../../binutils-2.35.1/gold/workqueue-threads.cc:117
#10 0x7fdc9444be6e in start_thread (arg=0x7fdc3c132640) at
pthread_create.c:463
#11 0x7fdc94381a5f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) info threads
Id Target Id Frame
* 1Thread 0x7fdc3c132640 (LWP 1087079)
gold::Pluginobj::get_symbol_resolution_info (this=0x7fdc10001010,
symtab=0x7ffe9622ef50, nsyms=, syms=,
version=) at ../../binutils-2.35.1/gold/plugin.cc:1293
2Thread 0x7fdc90147640 (LWP 1087058) futex_wait_cancelable (private=0,
expected=0, futex_word=0x55e7fe567d24) at ../sysdeps/nptl/futex-internal.h:183
...
32 Thread 0x7fdc2812d640 (LWP 1087084) futex_wait_cancelable (private=0,
expected=0, futex_word=0x55e7fe567d20) at ../sysdeps/nptl/futex-internal.h:183
"""
valgrind says with unexpected access happens at the same location::
"""
==1087267== Thread 30:
==1087267== Invalid read of size 1
==1087267==at 0x458800:
gold::Pluginobj::get_symbol_resolution_info(gold::Symbol_table*, int,
ld_plugin_symbol*, int) const (plugin.cc:1295)
==1087267==by 0x484BC79: write_resolution (lto-plugin.c:569)
==1087267==by 0x484BC79: all_symbols_read_handler (lto-plugin.c:749)
==1087267==by 0x45704E: all_symbols_read (plugin.cc:403)
==1087267==by 0x45704E:
gold::Plugin_manager::all_symbols_read(gold::Workqueue*, gold::Task*,
gold::Input_objects*, gold::Symbol_table*, gold::Dirsearch*, gold::Mapfile*,
gold::Task_token**) (plugin.cc:856)
==1087267==by 0x45718B: gold::Plugin_hook::run(gold::Workqueue*)
(plugin.cc:1770)
==1087267==by 0x4B2A6F: gold::Workqueue::find_and_run_task(int)
(workqueue.cc:319)
==1087267==by 0x4B2CC9: gold::Workqueue::process(int) (workqueue.cc:495)
==1087267==by 0x4B2E22: process (workqueue-internal.h:92)
==1087267==by 0x4B2E22: gold::Workqueue_thread::thread_body(void*)
(workqueue-threads.cc:117)
==1087267==by 0x4B42E6D: start_thread (pthread_create.c:463)
==1087267==by 0x4C55A5E: clone (clone.S:95)
==1087267== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==1087267==
==1087267==
==1087267== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
"""
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/23607] gold linker --threads --thread-count,2 causes ld segmentation fault
https://sourceware.org/bugzilla/show_bug.cgi?id=23607 Sergei Trofimovich changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from Sergei Trofimovich --- binutils from master does not seem to crash on a simple test from #comment7. Bisected the fix down to https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=d4820dac5e7608e24fba6d08cde9248b4c4b2928 """ $ git bisect bad d4820dac5e7608e24fba6d08cde9248b4c4b2928 is the first bad commit commit d4820dac5e7608e24fba6d08cde9248b4c4b2928 Author: H.J. Lu Date: Sun Nov 8 04:10:01 2020 -0800 gold: Avoid sharing Plugin_list::iterator class Plugin_manager has // A pointer to the current plugin. Used while loading plugins. Plugin_list::iterator current_; The same iterator is shared by all threads. It is OK to use it to load plugins since only one thread loads plugins. Avoid sharing Plugin_list iterator in all other cases. PR gold/26200 * plugin.cc (Plugin_manager::claim_file): Don't share Plugin_list iterator. (Plugin_manager::all_symbols_read): Likewise. (Plugin_manager::cleanup): Likewise. gold/ChangeLog | 8 gold/plugin.cc | 34 +- 2 files changed, 25 insertions(+), 17 deletions(-) """ Looks related. Dupe of bug #26200? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27122] New: ld -r does not complain about LTO/non-LTO mix and silently produces invalid object files.
https://sourceware.org/bugzilla/show_bug.cgi?id=27122
Bug ID: 27122
Summary: ld -r does not complain about LTO/non-LTO mix and
silently produces invalid object files.
Product: binutils
Version: 2.36 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
CC: hjl.tools at gmail dot com
Target Milestone: ---
Re-discovered in https://github.com/gentoo-haskell/gentoo-haskell/issues/1110.
PR12291 tracks support for mixed LTO/non-LTO objects. While it's not
implemented should ld complain about data loss when partial linking is used?
gcc's man page suggest it should but I'm not sure if it's ld's problem or gcc's
linker plugin problem.
gcc's manpage says:
```
-flinker-output=type
During the incremental link (by -r) the linker plugin defaults to
rel. With current interfaces to GNU Binutils it is however not possible to
incrementally link LTO objects and
non-LTO objects into a single mixed object file. If any of object
files in incremental link cannot be used for link-time optimization, the linker
plugin issues a warning and
uses nolto-rel. To maintain whole program optimization, it is
recommended to link such objects into static library instead. Alternatively it
is possible to use H.J. Lu's
binutils with support for mixed objects.
```
Example session (models upstream bug):
$ cat a.c
void a(void) {}
$ cat b.c
void a(void); /* from non-lto */
int main(void) { a(); }
$ LANG=C bash -x ./mk.bash
+ x86_64-pc-linux-gnu-gcc-11.0.0 -c a.c
+ x86_64-pc-linux-gnu-gcc-11.0.0 -flto -c b.c
+ x86_64-pc-linux-gnu-gcc-11.0.0 a.o b.o -o o1
+ x86_64-pc-linux-gnu-ld -r a.o b.o -o o.o
+ x86_64-pc-linux-gnu-gcc-11.0.0 -flto o.o -o o2
/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/ccHmkp4T.ltrans0.ltrans.o: in function `main':
:(.text+0x5): undefined reference to `a'
collect2: error: ld returned 1 exit status
Note: `x86_64-pc-linux-gnu-ld -r a.o b.o -o o.o` issued no warnings.
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/22755] gold test suite failures (gentoo, 2.31)
https://sourceware.org/bugzilla/show_bug.cgi?id=22755 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru, ||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/27303] New: gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303
Bug ID: 27303
Summary: gold/testsuite/initpri3. test fails on gold and lld,
passes on bfd. Which one is correct?
Product: binutils
Version: 2.36
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: admin
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
The test fails as is on gold:
$ gcc-11.0.0 initpri3.c -o bug -fuse-ld=lld && ./bug
bug: initpri3.c:78: main: Assertion `i == 3' failed.
Aborted (core dumped)
$ gcc-11.0.0 initpri3.c -o bug -fuse-ld=gold && ./bug
bug: initpri3.c:40: ctor2: Assertion `i == 2' failed.
Aborted (core dumped)
$ gcc-11.0.0 initpri3.c -o bug -fuse-ld=bfd && ./bug
It looks like the difference here is how the array of `.ctors` is handled:
```
/* The .ctors section is run in reverse order, the .dtors section in
run in forward order. We give these arrays the "aligned" attribute
because the x86_64 ABI would otherwise give them a 16-byte
alignment, which may leave a hole in the section. */
void (*ctors[]) (void)
__attribute__ ((aligned (4), section (".ctors"))) = {
ctor2,
ctor1
};
```
The array is stored as one section:
```
.section.ctors,"aw"
.align 8
.type ctors, @object
.size ctors, 16
ctors:
.quad ctor2
.quad ctor1
```
In both cases linker reordered the elements within the array:
$ gcc-11.0.0 initpri3.c -fuse-ld=gold -o ig -ggdb3
$ gcc-11.0.0 initpri3.c -fuse-ld=bfd -o ib -ggdb3
$ gdb --quiet ./ib
Reading symbols from ./ib...
(gdb) print ctors
$1 = {0x1139 , 0x117d }
$ gdb --quiet ./ig
Reading symbols from ./ig...
(gdb) print ctors
$1 = {0x689 , 0x6cd }
But not within __init_array_start:
$ gdb --quiet ./ib
Reading symbols from ./ib...
(gdb) start
Temporary breakpoint 1 at 0x124d: file initpri3.c, line 78.
Starting program: /tmp/z/ib
Temporary breakpoint 1, main () at initpri3.c:78
78assert (i == 3);
(gdb) x/4a __init_array_start
0x7dc8: 0x5130 0x5139
0x7dd8 : 0x517d 0x50f0
gdb --quiet ./ig
Reading symbols from ./ig...
(gdb) start
Temporary breakpoint 1 at 0x79d: file initpri3.c, line 78.
Starting program: /tmp/z/ig
ig: initpri3.c:40: ctor2: Assertion `i == 2' failed.
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49return ret;
(gdb) x/4a __init_array_start
0x5db8: 0x4680 0x46cd
0x5dc8 : 0x4689 0x3
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug admin/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 Sergei Trofimovich changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=22755 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 Sergei Trofimovich changed: What|Removed |Added CC||ian at airs dot com Component|admin |gold -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 --- Comment #5 from Sergei Trofimovich --- (In reply to Cary Coutant from comment #2) > I haven't yet managed to get a clean build of GCC 11 to try to reproduce, > but I do have a suspicion. Gold reverses the .ctors entries in .init_array, > after applying relocations, but it does not attempt to reverse any dynamic > relocations. That's normally not an issue, as we shouldn't have dynamic > relocations for entries in the .ctors sections, but there might be something > forcing the linker to create them. (The clue is that you had to start the > process in gdb before printing the .init_array entries.) Ah, dynamic relocations is a good clue! I have dynamic relocations due to gcc being built with --enable-default-pie. Adding -no-pie makes tests pass. > Please attach the output of: > > readelf -rsW initpri3.o Will do. $ objdump -D -r initpri3.o does show relocations: Disassembly of section .ctors: : ... 0: R_X86_64_64 .text+0x44 8: R_X86_64_64 .text > readelf -rW initpri3a # (or ig from your example) Will do. > I'm tempted to remove the whole --ctors-in-init-array option and this test > case. GCC hasn't used the .ctors section in years now, as far as I know. > > But I'd like to understand what's causing this failure. If the cause is > dynamic relocations, I'd like to understand what's causing the linker to > generate them. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 --- Comment #6 from Sergei Trofimovich --- Created attachment 13200 --> https://sourceware.org/bugzilla/attachment.cgi?id=13200&action=edit initpri3.o.readelf initpri3.o.readelf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 --- Comment #7 from Sergei Trofimovich --- Created attachment 13201 --> https://sourceware.org/bugzilla/attachment.cgi?id=13201&action=edit initpri3a.readelf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 --- Comment #8 from Sergei Trofimovich --- (In reply to Cary Coutant from comment #4) > Works for me with GCC 11 (1/31/21 snapshot). > > Please also throw in a -v option on your gcc command and attach the verbose > output. I'd like to see what options your compiler is passing to the linker. I think it's -fPIE / -pie from --enable-default-pie. $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.0.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/python --enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.0.0_pre p6, commit 33a1e511b57465d898429740377466894a0b247d' --disable-esp --enable-libstdcxx-time --enable-host-shared --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --enable-valgrind-annotations --enable-vtable-verify --with-zstd --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20210201 (experimental) (Gentoo 11.0.0_pre p6, commit 33a1e511b57465d898429740377466894a0b247d) Raw linker command: /usr/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -fuse-ld=gold -o ig /usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../lib64/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../.. /tmp/ccSMypjj.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../lib64/crtn.o -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27397] New: CET autodetection fails configure on i486 and i586 targets
https://sourceware.org/bugzilla/show_bug.cgi?id=27397 Bug ID: 27397 Summary: CET autodetection fails configure on i486 and i586 targets Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru CC: hjl.tools at gmail dot com Target Milestone: --- This is a forward of downstream bugs: https://bugs.gentoo.org/760926 https://bugs.gentoo.org/770061 https://bugs.gentoo.org/760926 is slightly more detailed. There user uses j6-3 machine (almst, but not quite i686). As a result configure detect CET support by assembler but test crashes at runtime failing ./configure: ``` configure:5391: i486-pc-linux-gnu-gcc -o conftest -pipe -O2 -march=k6-3 -m3dnow -mmmx -fomit-frame-pointer -ftree-vectorize -mno-sse -mno-sse2 -mno-sse3 -mno-ssse3 -mno-sse4.1 --param l1-cache-size=32 --param l1-cache-line-size=32 --param l2-cache-size=256 -mtune=k6 -fcf-protection=none -Wl,-O1 -Wl,--as-needed -Wl,-z,ibt,-z,shstk conftest.c >&5 configure:5391: $? = 0 configure:5391: ./conftest /var/tmp/portage/sys-devel/gdb-10.1/work/gdb-10.1/libiberty/configure: line 1624: 853 Illegal instruction ./conftest$ac_exeext configure:5391: $? = 132 configure: program exited with status 132 configure:5401: error: Intel CET must be enabled on Intel CET enabled host ``` Looks like the only way to get binutils and gdb on old machines is to pass --disable-cet explicitly to ./configure. Is it an intended behaviour? Gentoo packages binutils-gdb in a few flavours: - binutils - gdb - binutils-libs - binutils-hppa64 and we need to duplicate the --disable-cet everywhere. I ended up disabling CET for all architectures including x86_64 out of laziness. Would be nice if ./configure picked a better default. I suggest tweaking upstream configure to silently disable the features instead of failing configure at least on non-x86_64 to make packaging slightly smoother. WDYT? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27397] CET autodetection fails configure on i486 and i586 targets
https://sourceware.org/bugzilla/show_bug.cgi?id=27397 --- Comment #2 from Sergei Trofimovich --- (In reply to H.J. Lu from comment #1) > Created attachment 13218 [details] > A patch > > Please try this. Asked user to try in https://bugs.gentoo.org/770061#c16, failed in a simialr way. I'll debug with user a bit more to better understand the problem and come back. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27397] CET autodetection fails configure on i486 and i586 targets
https://sourceware.org/bugzilla/show_bug.cgi?id=27397 --- Comment #3 from Sergei Trofimovich --- Created attachment 13219 --> https://sourceware.org/bugzilla/attachment.cgi?id=13219&action=edit binutils-gdb-fix-cet.patch We debugged it in https://bugs.gentoo.org/attachment.cgi?id=686394 a bit more and managed to work around the failure with: binutils-gdb-fix-cet.patch But it's not a correct patch. Revised explanation of failure mode: 1. toolchain does not support sse2 (good, intended) 2. That leads to enable_cet=no autodetection (good, intended) 3. Then '# Check whether -fcf-protection=none -Wl,-z,ibt,-z,shstk work.' test is ran. 'endbr' instructions are injected (via PLT stubs for shstk?). 4 That makes the test fail with SIGILL when ran on pre-SSE CPUs. 5. have_cet=yes is raised (UNINTENDED). O think 'have_cet=' is shightly misleading. I suggest renaming it to 'requires_cet='. 6 ./configure fails with: if test x$enable_cet = xno -a x$have_cet = xyes; then AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host]) fi Another possibility is to turn have_cet=yes to a positive test: if CET can run successfully then enable it (attached patch tries to do it, but incorrectly) (or if disabled CET makes minimal binaries crash?). But it requires more work as './configure --disable-cet' fails with it. Or slightly change your patch to do similar disabling on AC_TRY_RUN side instead. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27397] CET autodetection fails configure on i486 and i586 targets
https://sourceware.org/bugzilla/show_bug.cgi?id=27397 --- Comment #6 from Sergei Trofimovich --- (In reply to H.J. Lu from comment #5) > Created attachment 13220 [details] > An updated patch > > Try this. The user reports it's building fine for them on i486: https://bugs.gentoo.org/770061#c26 AFAIU event with the patch ./configure --host=i686-pc-linux-gnu if ran on pre-sse2 CPU, right? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27397] CET autodetection fails configure on i486 and i586 targets
https://sourceware.org/bugzilla/show_bug.cgi?id=27397 --- Comment #8 from Sergei Trofimovich --- (In reply to H.J. Lu from comment #7) > (In reply to Sergei Trofimovich from comment #6) > > (In reply to H.J. Lu from comment #5) > > > Created attachment 13220 [details] > > > An updated patch > > > > > > Try this. > > > > The user reports it's building fine for them on i486: > > https://bugs.gentoo.org/770061#c26 > > > > AFAIU event with the patch ./configure --host=i686-pc-linux-gnu if ran on > > pre-sse2 CPU, right? > > SSE2 isn't the issue. The multi-byte NOP is the issue. Oh, I thought these multibyte NOP come from SSE2 encoding. I'd like to understand why then these NOPs crash the program with SIGILL. Looking at endbr32 instruction as an example: "F3 0F 1E FB". Do I understand correctly it's supposed to be decoded by old CPUs as: prefix=F3 (REP) escape="0F 1E" (Reserved-NOP) modrm(?)=FB Do you know when these 'Reserved-NOP' were introduced as valid instruction to IA-32? I wonder why K6-III can't handle it: is it a CPU bug (imprecise implementation of reserved NOPs) or it was introduced later. -- You are receiving this mail because: You are on the CC list for the bug.
