[Bug ld/17117] New: assertion fail elf32-i386.c:4016
https://sourceware.org/bugzilla/show_bug.cgi?id=17117
Bug ID: 17117
Summary: assertion fail elf32-i386.c:4016
Product: binutils
Version: 2.25 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
Created attachment 7680
--> https://sourceware.org/bugzilla/attachment.cgi?id=7680&action=edit
repro input
When trying to build pixman with -mtls-dialect=gnu2, ld produces assertion
failure while gold appears to work. To reproduce with the attached file:
ld -m elf_i386 -shared -o libpixman-1.so.0.32.4 pixman-implementation.o
/tmp/binutils-build/ld/ld-new: BFD (GNU Binutils) 2.24.51.20140703 assertion
fail ../../binutils-2.24.51/bfd/elf32-i386.c:4016
(gdb) list
4011 if (GOT_TLS_GDESC_P (tls_type))
4012{
4013 bfd_byte *loc;
4014 outrel.r_info = ELF32_R_INFO (indx, R_386_TLS_DESC);
4015 BFD_ASSERT (htab->sgotplt_jump_table_size + offplt + 8
4016 <= htab->elf.sgotplt->size);
(gdb) p htab.sgotplt_jump_table_size
$1 = 60
(gdb) p offplt
$2 = 16
(gdb) p htab.elf.sgotplt.size
$3 = 80
--
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/17117] [2.23 Regression] assertion fail elf32-i386.c:4016 with GNU2 TLS
https://sourceware.org/bugzilla/show_bug.cgi?id=17117 Alexander Monakov changed: What|Removed |Added CC||hjl.tools at gmail dot com See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=17057 Summary|assertion fail |[2.23 Regression] assertion |elf32-i386.c:4016 |fail elf32-i386.c:4016 with ||GNU2 TLS --- Comment #1 from Alexander Monakov --- Bug #17057 looks related if not the same. This appears to be a regression starting from the following commit: commit e1f987424b7b3f5ac63a2a6ae044a202a44b8ff8 Author: H.J. Lu Date: Fri Oct 21 15:13:37 2011 + Put IRELATIVE relocations after JUMP_SLOT. bfd/ 2011-10-21 H.J. Lu PR ld/13302 * elf32-i386.c (elf_i386_link_hash_table): Add next_jump_slot_index and next_irelative_index. (elf_i386_link_hash_table_create): Initialize next_jump_slot_index and next_irelative_index. (elf_i386_allocate_dynrelocs): Increment reloc_count instead of next_tls_desc_index. (elf_i386_size_dynamic_sections): Set next_tls_desc_index and next_irelative_index from reloc_count. (elf_i386_finish_dynamic_symbol): Put R_386_IRELATIVE after R_386_JUMP_SLOT. -- 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/17057] Production of DSOs using TLSDESC is utterly broken on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=17057 Alexander Monakov changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=17117 -- 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/18841] New: Data relocations with IFUNC symbols can lead to segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=18841
Bug ID: 18841
Summary: Data relocations with IFUNC symbols can lead to
segfault
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
In the following testcase, libfoo.so is compiled so that it has GLOB_DAT
relocations against 'foo' and 'zoo', in that order (with BFD linker), which
leads to failure at dynamic linking time. Renaming 'zoo' to 'z' with the
preprocessor avoids the segfault (the relocations happen to be emitted in the
opposite order). Gold linker appears to always sort the relocations
"properly".
cat <foo.c
void foo() __attribute__((ifunc("resolve_foo")));
static void foo_impl() {}
void test()
{
void (*pg)(void) = foo;
pg();
}
static void* resolve_foo()
{
extern void zoo(void);
void (*pz)(void) = zoo;
pz();
return foo_impl;
}
EOF
cat <main.c
void zoo(){}
void test(void);
int main()
{
test();
return 0;
}
EOF
cat <<'EOF' >Makefile
test: main; ./main
main: libfoo.so
lib%.so: %.c; $(CC) $(CFLAGS) -fPIC -shared -o $@ $<
main: LDLIBS=-L. -lfoo
main: LDFLAGS=-Wl,-rpath,.
EOF
$ make -B CFLAGS=-fuse-ld=gold
cc -fuse-ld=gold -fPIC -shared -o libfoo.so foo.c
cc -fuse-ld=gold -Wl,-rpath,. main.c libfoo.so -L. -lfoo -o main
./main
$ make -B CFLAGS=-fuse-ld=bfd
cc -fuse-ld=bfd -fPIC -shared -o libfoo.so foo.c
cc -fuse-ld=bfd -Wl,-rpath,. main.c libfoo.so -L. -lfoo -o main
./main
Makefile:2: recipe for target 'test' failed
make: *** [test] Segmentation fault
$ make -B CFLAGS=-fuse-ld=bfd\ -Dzoo=z
cc -fuse-ld=bfd -Dzoo=z -fPIC -shared -o libfoo.so foo.c
cc -fuse-ld=bfd -Dzoo=z -Wl,-rpath,. main.c libfoo.so -L. -lfoo -o main
./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/18841] Data relocations with IFUNC symbols can lead to segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=18841 --- Comment #5 from Alexander Monakov --- Does it still fail with the change you mentioned in comment #2? > 2. Make pz file scope causes it to fail with gold and ld -- 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/18829] Add the ability to sort PLT entries
https://sourceware.org/bugzilla/show_bug.cgi?id=18829 Alexander Monakov changed: What|Removed |Added CC||amonakov at gmail dot com --- Comment #3 from Alexander Monakov --- As I understand, for further benefit you should sort the GOT as well as PLT based on the same idea — and that will save you some dcache misses even with -fno-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/21557] New: __start_SCN not provided if SCN used in linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=21557
Bug ID: 21557
Summary: __start_SCN not provided if SCN used in linker script
Product: binutils
Version: 2.29 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
Target Milestone: ---
It appears that automagic provision of __start_/__stop_SCN symbol names doesn't
work in BFD linker (works in Gold) if the section in question participates in
linker script SECTIONS command, even though computing reachability for the
purposes of --gc-sections works as expected.
cat <test.s
.sectionscnfoo,"aw",@progbits
.type foo, @object
.size foo, 1
foo:
.zero 1
.globl bar
.data
.align 8
.type bar, @object
.size bar, 8
bar:
.quad __start_scnfoo
EOF
cat <lds
SECTIONS {
scnfoo : { *(scnfoo) }
}
EOF
gcc -B. -fuse-ld=bfd -shared -o test.so test.o -Wl,-z,defs -T lds
test.o:(.data+0x0): undefined reference to `__start_scnfoo'
(this issue is minimized from analyzing why Glibc libc.so gets mislinked with
--gc-sections, but the original Glibc issue is different: they use PROVIDE
statements overriding magic symbols:
PROVIDE(__start___libc_subfreeres = .);
__libc_subfreeres : { *(__libc_subfreeres) }
PROVIDE(__stop___libc_subfreeres = .);
and imho there the main question would be if linkers want to support such
usage, or Glibc would have to drop the now-useless PROVIDE statements to allow
building with --gc-sections, but that leads to the above ld.bfd bug)
--
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/21557] __start_SCN not provided if SCN used in linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=21557
--- Comment #2 from Alexander Monakov ---
Thanks for the reference, I was missing that this handling is explicitly
limited to orphan sections. This makes my testcase invalid, but please consider
that current linker behavior appears inconsistent, for two separate reasons.
First, gc-sections considers these non-orphan sections reachable; taking the
testcase and linking it without '-z defs', with --gc-sections, you get:
$ ld.bfd -shared -o test.so test.o --gc-sections --print-gc-sections -T lds
But eliminating the reference from 'bar' allows it to be collected:
$ sed -i -e s/__start_scnfoo/undef/ test.s
$ gcc -c test.s
$ ld.bfd -shared -o test.so test.o --gc-sections --print-gc-sections -T lds
ld.bfd: Removing unused section 'scnfoo' in file 'test.o'
To the user this means that __start_scnfoo was virtually present when sections
were marked for garbage-collection, but not present for actual symbol
resolution.
Second, it implies there's no good way to use linker-scripts, --gc-sections and
__start_SCN together, even if one's use of linker scripts is limited to
rearranging sections. If one tries to manually provide __start_SCN:
SECTIONS {
.dynamic : { *(.dynamic) }
.data : { *(.data) }
PROVIDE(__start_scnfoo = .);
scnfoo : { *(scnfoo) }
}
... then it leads to scnfoo eliminated with --gc-sections because
__start_scnfoo no longer ties it to public symbol 'bar':
ld.bfd -shared -o test.so test.o --gc-sections --print-gc-sections -T lds
ld.bfd: Removing unused section 'scnfoo' in file 'test.o'
(with linker scripts it's possible to have output sections have different names
than input sections, this may cause ambiguity in what SCN __start_SCN should be
referring to; is that the reason why handling is limited to orphans?)
(it's not clear to me why bug status was set to WAITING, please clarify if
you'd like to see further clarifications, new bugreports for above issues, or
something else)
--
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/21562] New: Refs to __start_SCN of non-orphan sections affect --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=21562
Bug ID: 21562
Summary: Refs to __start_SCN of non-orphan sections affect
--gc-sections
Product: binutils
Version: 2.29 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
Target Milestone: ---
(originally mentioned in bug 21557)
Linker manual explicitly states that __start_SCN symbols are automatically
provided only for orphan sections. However, the following testcase shows that
such symbols appear virtually present when marking reachable sections for
--gc-sections:
cat <test.s
.sectionscnfoo,"aw",@progbits
.zero 1
.globl bar
.data
.align 8
.type bar, @object
.size bar, 8
bar:
.quad __start_scnfoo
EOF
cat <lds
SECTIONS {
scnfoo : { *(scnfoo) }
}
EOF
$ ld.bfd -shared -o test.so test.o --gc-sections --print-gc-sections -T lds
--
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/21557] __start_SCN not provided if SCN used in linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=21557
--- Comment #4 from Alexander Monakov ---
> Please open a new bug report.
Done, bug 21562.
Now I see that to use __start_SCN together with linker scripts and
--gc-sections, one should put the PROVIDE statement inside of the output
section declaration:
SECTIONS {
scnfoo : {
PROVIDE_HIDDEN(__start_scnfoo = .);
*(scnfoo)
}
}
This looks logical and seems to work with -gc-sections, with both ld.bfd and
Gold. I think the Glibc approach quoted in comment #0 with PROVIDE statements
outside of output groups sets a bad example (and breaks build with
--gc-sections).
--
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/21562] Refs to __start_SCN of non-orphan sections affect --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=21562 --- Comment #5 from Alexander Monakov --- The patch looks wrong, it appears to ensure that __start_scnfoo is defined. The linker manual says it shouldn't get defined (scnfoo is not orphan), and therefore scnfoo should be eliminated due to --gc-sections. (note that bug 20022 and bug 19167 are both for orphan sections, linker scripts are not involved there) -- 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/21562] Refs to __start_SCN of non-orphan sections affect --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=21562 --- Comment #7 from Alexander Monakov --- (In reply to H.J. Lu from comment #6) > I posted a patch to always define referenced __start_SECNAME/__stop_SECNAME: That's quite confusing, because originally bug 21557 (wrongly) complained about those symbols not being defined, and you closed that bug as WONTFIX. If you changed your mind, can you please update that bug? I don't see the reason to extend __start_SECNAME auto-provisioning, it seems it would be simpler to avoid extraneous gc-marking shown in this bug. -- 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/21571] --gc-sections doesn't work with PROVIDE in linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=21571 Alexander Monakov changed: What|Removed |Added CC||amonakov at gmail dot com --- Comment #3 from Alexander Monakov --- This is a regression in 2.28 and HEAD, release 2.27 got this right. Bisecting points to: f02cb058822459ea29a9fdaa928c2623df435908 is the first bad commit commit f02cb058822459ea29a9fdaa928c2623df435908 Author: Alan Modra Date: Tue Oct 11 18:13:04 2016 +1030 Always descend into output section statements in lang_do_assignments -- 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/29551] Wrong relocations against _GLOBAL_OFFSET_TABLE_
https://sourceware.org/bugzilla/show_bug.cgi?id=29551 Alexander Monakov changed: What|Removed |Added CC||amonakov at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/22566] New: --gc-sections preserves hidden symbols if initial definition has default visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=22566 Bug ID: 22566 Summary: --gc-sections preserves hidden symbols if initial definition has default visibility Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: amonakov at gmail dot com CC: ian at airs dot com Target Milestone: --- ELF spec states that the most constraining visibility is taken from all definitions and references to the symbol to find the final visibility status. In the following example, Gold correctly computes the final visibility (hidden, taken from t2.o), but if t1.o comes first on the command line, Gold marks foo as a GC root too early. The BFD linker gets this right in both cases. t1.s: .globl foo foo: .zero 4096 t2.s: .hidden foo .int foo-. $ ld.gold -shared -gc-sections t2.o t1.o && size -A a.out | grep text [no output, -gc-sections works as expected] $ ld.gold -shared -gc-sections t1.o t2.o && size -A a.out | grep text .text4096464 $ readelf -a a.out |grep foo 1: 01d0 0 NOTYPE LOCAL HIDDEN 4 foo -- 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/22649] New: -gc-sections preserves hidden symbols that are also visible in dynamic objects
https://sourceware.org/bugzilla/show_bug.cgi?id=22649 Bug ID: 22649 Summary: -gc-sections preserves hidden symbols that are also visible in dynamic objects Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: amonakov at gmail dot com Target Milestone: --- Consider the follow testcase with two shared libraries: $ cat > lib1.s .globl foo foo: $ cat > lib2.s .hidden foo .hidden bar .globl foo .globl bar foo: bar: call foo@PLT $ gcc -c *.s $ ld-new -shared -o lib1.so lib1.o $ ld-new -shared -o lib2.so lib2.o -gc-sections -print-gc-sections ld-new: Removing unused section '.text' in file 'lib2.o' $ ld-new -shared -o lib2.so lib2.o -gc-sections -print-gc-sections lib1.so [no output] This is surprising: somehow specifying lib1.so on the command line has the effect of pinning "foo" as a GC root. -- 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/22694] [2.30 Regression] -fuse-ld=gold not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=22694 Alexander Monakov changed: What|Removed |Added CC||amonakov at gmail dot com --- Comment #6 from Alexander Monakov --- Please reconsider. collect2 has always passed through -fuse-ld= to the linker, and gold has accepted (and ignored) it until the recent commit 7ef67ba5339 that was supposed to fix PR 22042. Now gold simply segfaults when given the option without an argument, while before it was ignored (as intended). And the functionality that was supposed to ignore the option does not work anymore for some reason. $ gdb --args /mnt/build/binutils/gold/ld.gold -fuse-ld [...] (gdb) r Starting program: /mnt/build/binutils/gold/ld.gold -fuse-ld bt Program received signal SIGSEGV, Segmentation fault. gold::options::parse_string (option_name=0x7fffe18e "-fuse-ld", arg=0x0, retval=retval@entry=0x7fff7200) at /mnt/checkout/binutils-gdb/gold/options.cc:253 253 if (*arg == '\0') (gdb) bt #0 gold::options::parse_string (option_name=0x7fffe18e "-fuse-ld", arg=0x0, retval=retval@entry=0x7fff7200) at /mnt/checkout/binutils-gdb/gold/options.cc:253 #1 0x00429f03 in gold::General_options::Struct_fuse_ld::parse_to_value (this=0x7fff7198, option_name=, arg=) at /mnt/checkout/binutils-gdb/gold/options.h:895 #2 0x0065a047 in gold::Command_line::process_one_option (this=this@entry=0x7fff4b30, argc=argc@entry=1, argv=argv@entry=0x7fffde30, i=i@entry=0, no_more_options=no_more_options@entry=0x7fff3fdf) at /mnt/checkout/binutils-gdb/gold/options.cc:1523 #3 0x0065b985 in gold::Command_line::process (this=this@entry=0x7fff4b30, argc=1, argv=0x7fffde30) at /mnt/checkout/binutils-gdb/gold/options.cc:1565 #4 0x00407c3a in main (argc=, argv=) at /mnt/checkout/binutils-gdb/gold/main.cc:165 -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 Alexander Monakov changed: What|Removed |Added CC||amonakov at gmail dot com --- Comment #1 from Alexander Monakov --- I think the behavior exhibited by gold is expected given absence of --whole-archive, and it's ld.bfd that is doing something not mandated by the ELF spec here. -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 --- Comment #7 from Alexander Monakov --- BFD's behavior becomes very problematic with LTO: archive index does not distinguish between normal and common definitions, and there's no explicit plugin API to check if a definition in IR is "common", so the linker has to round-trip via the plugin in a fairly convoluted way to emulate the non-LTO behavior :( I think it would be prudent to understand *why* ld.bfd wants to override common definitions by unpacking archive members with strong definitions. I don't expect it's for Fortran - is the real reason stated anywhere? -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 --- Comment #9 from Alexander Monakov --- (In reply to Cary Coutant from comment #8) > Is that a problem we really need to worry > about? The only real issue with including an otherwise-unneeded object > is the potential violation of the language's namespace pollution rules > (see below). The reason it's being reported now is complications with plugin interaction. Recently, GCC strengthened internal consistency checks for LTO symbol resolution, and (combined with arguably poor choices for statuses reported for symbols coming from unused members) they fail when such unpacked-but-unused archive members get involved: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 I'm chiming in because I've been working on a third party (i.e. non-GCC, non-LLVM) linker plugin recently, and this ld.bfd-specific behavior was completely unexpected and cost some time. The ELF specification does not allow this, the other docs I consulted did not mention it, and the way ar index is built suggests common status is irrelevant for extraction (otherwise the index would include the common flag). If the BFD behavior is really intended, can at least the documentation please be improved to explain that? And what would really help is a dedicated plugin API entrypoint to allow the linker ask the plugin, "does IR in this file provide a strong definition for any currently common symbol in this array: ["foo", "bar", ...]?" -- 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/23935] [Regression] ld.bfd does not rescan fat LTO archives to resolve plugin-added references
https://sourceware.org/bugzilla/show_bug.cgi?id=23935 Alexander Monakov changed: What|Removed |Added CC||amonakov 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/27119] ld improperly relocates function address, creating an invalid pointer
https://sourceware.org/bugzilla/show_bug.cgi?id=27119
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
--- Comment #4 from Alexander Monakov ---
(In reply to H.J. Lu from comment #3)
> Don't use
>
> OUTPUT_FORMAT("binary")
>
> with backend specific relocations, like R_X86_64_GOTPCRELX, since the
> generic binary linker can't process them properly.
If some part of the linker cannot process a particular relocation, why is it
emitting random nonsense instead of issuing a diagnostic message and stopping
with an error?
How is this "Not a bug"? This is a valid quality-of-implementation issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32846] LTO link failures in various packages since 2707d55e539ef323dd14a1293e762bf3d9739ee7
https://sourceware.org/bugzilla/show_bug.cgi?id=32846 Alexander Monakov changed: What|Removed |Added CC||amonakov at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
