[Bug gold/20442] New: R_SPARC_GOTDATA_OP_LOX10 incorrectly falls back on R_SPARC_GOT13
https://sourceware.org/bugzilla/show_bug.cgi?id=20442 Bug ID: 20442 Summary: R_SPARC_GOTDATA_OP_LOX10 incorrectly falls back on R_SPARC_GOT13 Product: binutils Version: 2.27 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: jrtc27 at jrtc27 dot com CC: ccoutant at gmail dot com, ian at airs dot com Target Milestone: --- The fall-through in Target_sparc::Relocate::relocate for R_SPARC_GOTDATA_OP_LOX10 is currently R_SPARC_GOT13, but should clearly be R_SPARC_GOT10. GCC has been seen to emit a sethi/xor rather than a sethi/or sequence to load a 32-bit immediate, but if R_SPARC_GOT13 is used then bits 10-12 get zeroed out as both the sethi and xor immediates contain them. Patch available at https://www.sourceware.org/ml/binutils/2016-07/msg00161.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 gold/20441] New: Allow R_SPARC_32 on sparc64
https://sourceware.org/bugzilla/show_bug.cgi?id=20441 Bug ID: 20441 Summary: Allow R_SPARC_32 on sparc64 Product: binutils Version: 2.27 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: jrtc27 at jrtc27 dot com CC: ccoutant at gmail dot com, ian at airs dot com Target Milestone: --- R_SPARC_32 is currently forbidden in gold, but allowed in bfd. Patch available at https://www.sourceware.org/ml/binutils/2016-07/msg00160.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 gold/20441] Allow R_SPARC_32 on sparc64
https://sourceware.org/bugzilla/show_bug.cgi?id=20441 James Clarke changed: What|Removed |Added Host||sparc64-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 gold/20442] R_SPARC_GOTDATA_OP_LOX10 incorrectly falls back on R_SPARC_GOT13
https://sourceware.org/bugzilla/show_bug.cgi?id=20442 James Clarke changed: What|Removed |Added Host||sparc64-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 gold/20443] New: Segfaults with STT_SPARC_REGISTER and --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20443
Bug ID: 20443
Summary: Segfaults with STT_SPARC_REGISTER and --gc-sections
Product: binutils
Version: 2.27
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: jrtc27 at jrtc27 dot com
CC: ccoutant at gmail dot com, ian at airs dot com
Target Milestone: ---
Host: sparc64-linux-gnu
Easy reproduction:
$ cat main.c
int main() {
return 0;
}
$ gcc -o main -Wl,--gc-sections main.c
$ gcc -fuse-ld=gold -o main -Wl,--gc-sections main.c
collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
compilation terminated.
This is because res->is_externally_visible is called inside
Symbol_table::add_from_relobj when res is NULL (since this is an
STT_SPARC_REGISTER dummy symbol).
Patch available at
https://www.sourceware.org/ml/binutils/2016-07/msg00321.html.
With this patch I've done the obvious bare minimum to get this to work, but
given these NULLs are floating around now I highly suspect there will be other
places where they crop up.
--
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/21444] internal error in relocate_tls, at ../../gold/sparc.cc:3789
https://sourceware.org/bugzilla/show_bug.cgi?id=21444 --- Comment #5 from James Clarke --- This applies to 2.28 too (in fact this has existed for as long as gold has supported TLS relaxation on sparc). Could you please backport it? 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/21444] internal error in relocate_tls, at ../../gold/sparc.cc:3789
https://sourceware.org/bugzilla/show_bug.cgi?id=21444 --- Comment #1 from James Clarke --- I submitted a patch for this to the mailing list a week ago - https://sourceware.org/ml/binutils/2017-04/msg00276.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/19579] [Regression] link error linking fortran code with PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=19579 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #24 from James Clarke --- This is still broken on AArch64. I have just submitted a patch to the mailing list. -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #2 from James Clarke --- Proposed patch: https://sourceware.org/ml/binutils/2017-10/msg00224.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 gold/21868] [2.29/2.30 Regression] ICE in fix_errata_and_relocate_erratum_stubs, at ../../gold/aarch64.cc:1999
https://sourceware.org/bugzilla/show_bug.cgi?id=21868 --- Comment #3 from James Clarke --- Proposed patch at https://sourceware.org/ml/binutils/2017-08/msg00301.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 gold/21868] [2.29/2.30 Regression] ICE in fix_errata_and_relocate_erratum_stubs, at ../../gold/aarch64.cc:1999
https://sourceware.org/bugzilla/show_bug.cgi?id=21868 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 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/22592] dyn_reloc count error for sparc PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=22592 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #3 from James Clarke --- Created attachment 10684 --> https://sourceware.org/bugzilla/attachment.cgi?id=10684=edit Proposed patch I debugged this a few months ago as we were occasionally seeing it in Debian but never sent this upstream. The problem is because allocate_dynrelocs doesn't allocate enough GOT slots for PIC code, which is fixed by the second hunk of this patch. The other two hunks are cleanups which add other edge cases handled by other architectures but not SPARC. -- 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/22592] dyn_reloc count error for sparc PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=22592 --- Comment #4 from James Clarke --- (In reply to James Clarke from comment #3) > Created attachment 10684 [details] > Proposed patch > > I debugged this a few months ago as we were occasionally seeing it in Debian > but never sent this upstream. The problem is because allocate_dynrelocs > doesn't allocate enough GOT slots for PIC code, which is fixed by the second > hunk of this patch. The other two hunks are cleanups which add other edge > cases handled by other architectures but not SPARC. The only problem I've seen with this patch is that it now over-allocates relocations for the GOT. gdop_relative_offset_ok is only used after the GOT has been allocated, so any slots which are for objects "near" the GOT will be unused and end up as R_SPARC_NONE's padding the end of the GOT. For sparc32 we could add extra checks in allocate_dynrelocs to precisely determine whether gdop_relative_offset_ok will return TRUE for that symbol (as the entire address space is reachable with a 32-bit offset from the GOT), but for sparc64 we can't in general know if a symbol will be reachable or not that early. -- 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/22233] [2.29 Regression] gold segfault in relocate_erratum_stub on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22233 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #3 from James Clarke --- Oh, that's unfortunate, I managed to break the one is_input_output_view case that was being handled correctly. You could cancel the +/- view_offset pair in your patch, though what you've done is arguably clearer (and more obviously correct), at least to me. -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 --- Comment #12 from James Clarke --- (In reply to H.J. Lu from comment #9) > Symbol table is wrong: > > --- 2 2017-11-14 08:54:05.933477729 -0800 > +++ 1 2017-11-14 08:54:23.381514511 -0800 > @@ -84,7 +84,7 @@ Symbol table '.symtab' contains 10 entri > 5: 0 SECTION LOCAL DEFAULT7 > 6: 0 SECTION LOCAL DEFAULT9 > 7: 0 FILELOCAL DEFAULT ABS pr22266_a.c > - 8: fffc 4 OBJECT LOCAL DEFAULT2 int_from_a_1 > ^^ Good > > + 8: 4 OBJECT LOCAL DEFAULT2 int_from_a_1 > ^^^ Bad > 9: 4 OBJECT GLOBAL DEFAULT4 p_int_from_a_2 It's not that the symbol table was wrong. Your so-called "good" version is wrong; the symbol is at offset 0 from its section .data, so it really should have value 0 in the object file like it does now. The problem is that, it seems, somewhere, the REL was accounting for this (which is probably why the symbol value issue was not noticed earlier), and now that the symbol value is fixed, the REL case is broken. You can see for yourself that the problem is that the object file contents at "p_int_from_a_2" is 0x4, but this addend should be 0. -- 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/22832] 2.30 internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym
https://sourceware.org/bugzilla/show_bug.cgi?id=22832
--- Comment #4 from James Clarke ---
So, after debugging this, the problem is as follows:
Rust is using LLVM with -integrated-as (at least effectively; it may well be
using it as a library and setting the flag itself, but the point is that the
lowered IR is fed straight into the object code backend rather than being
serialised via assembly and then assembled separately). LLVM's
SparcMCCodeEmitter::getCallTargetOpValue handles __tls_get_addr specially to
not emit an R_SPARC_WDISP30/WPLT30, and somewhere else the R_SPARC_TLS_LDM_CALL
gets emitted, but the important point is that __tls_get_addr is never added to
the output object file's symbol table despite being the symbolic operand to the
call instruction.
Thus, when linking one of these object files, that object file's hash table
never pulls in the definition of __tls_get_addr, and so when
_bfd_sparc_elf_check_relocs is called for an R_SPARC_TLS_LDM_CALL, it looks up
__tls_get_addr, doesn't find it, and so an entry is created, since TRUE is
passed to bfd_link_hash_lookup for create, but this entry has type
bfd_link_hash_new, and this never changes.
So it seems to me there are two issues here:
1. LLVM should be emitting an entry for __tls_get_addr in its symbol table so
it is made visible to the object file.
2. ld should gracefully handle this case. If this case is an error, it should
instead be passing FALSE for create to bfd_link_hash_lookup, and if the result
is NULL, printing an error; otherwise, if this case should work, something
needs to implicitly pull in the symbol (and in theory LLVM doesn't need to
change, though in practice it's best to do so anyway for compatibility).
I've talked specifically about local-dynamic here for simplicity, but
global-dynamic has the same issue too.
Note that gold also falls foul of this, giving "gold: internal error in
tls_get_addr_sym, at ../../gold/sparc.cc:391", though line 391 is
"gold_assert(this->tls_get_addr_sym_);" which is much easier to debug!
Reproduction:
jrtc27@deb4g:~/tmp/22832$ cat 22832.c
__thread int x;
int f(void) { return x; }
jrtc27@deb4g:~/tmp/22832$ clang -integrated-as -o 22832.o -fPIC -c 22832.c
jrtc27@deb4g:~/tmp/22832$ readelf -Wrs 22832.o
Relocation section '.rela.text' at offset 0x138 contains 6 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0008 00030011 R_SPARC_PC22
_GLOBAL_OFFSET_TABLE_ + 4
000c 00030010 R_SPARC_PC10
_GLOBAL_OFFSET_TABLE_ + 8
0014 00050038 R_SPARC_TLS_GD_HI22 x +
0
0018 00050039 R_SPARC_TLS_GD_LO10 x +
0
001c 0005003a R_SPARC_TLS_GD_ADD x +
0
0020 0005003b R_SPARC_TLS_GD_CALL x +
0
Symbol table '.symtab' contains 6 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS 22832.c
2: 0 TLS LOCAL DEFAULT4 .tbss
3: 0 NOTYPE GLOBAL DEFAULT UND
_GLOBAL_OFFSET_TABLE_
4: 52 FUNCGLOBAL DEFAULT2 f
5: 4 TLS GLOBAL DEFAULT4 x
jrtc27@deb4g:~/tmp/22832$ ld -o lib22832.so -shared 22832.o
ld: BFD (GNU Binutils) 2.30.51.20180211 internal error, aborting at
elflink.c:9710 in elf_link_output_extsym
ld: Please report this bug.
jrtc27@deb4g:~/tmp/22832$ gold -o lib22832.so -shared 22832.o
gold: internal error in tls_get_addr_sym, at ../../gold/sparc.cc:391
--
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/22832] 2.30 internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym
https://sourceware.org/bugzilla/show_bug.cgi?id=22832 --- Comment #7 from James Clarke --- (In reply to John Paul Adrian Glaubitz from comment #6) > (In reply to James Clarke from comment #4) > > Note that gold also falls foul of this, giving "gold: internal error in > > tls_get_addr_sym, at ../../gold/sparc.cc:391", though line 391 is > > "gold_assert(this->tls_get_addr_sym_);" which is much easier to debug! > > I'm actually getting the following internal error when trying to build > firefox on sparc64 during some rust code compilation: > > 1:32.84 = note: > /srv/glaubitz/firefox/mozilla-central/obj-sparc64-unknown-linux-gnu/build/ > unix/gold/ld: internal error in sized_finalize_symbol, at > ../../gold/symtab.cc:2937 > 1:32.84 collect2: error: ld returned 1 exit status > > Is this related? Possibly, but I'd expect it to trigger an assertion failure in tls_get_addr_sym before that as with my test case. I suggest you open a new bug for this (and if you have debug symbols in that build, run it under gdb and `p *sym` to see what symbol it's having issues with). -- 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/15904] ia64, ELF, 'Can't relax br (PCREL21B)' error message on --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=15904 --- Comment #7 from James Clarke --- (In reply to Jim Wilson from comment #5) > Updated patch committed. Great, thanks! Could you please consider backporting it to the 2.30 branch? -- 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 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #9 from James Clarke --- Created attachment 11124 --> https://sourceware.org/bugzilla/attachment.cgi?id=11124=edit Updated/fixed patch The original patch on this bug report looks at whether the symbol in question is in a read-only section, but that should have no effect on whether this symbol needs to be copied into the executable. Instead, it should be checking whether there are any relocations in read-only sections referring to the symbol, as that determines whether we are able to leave in dynamic relocations. Ben's rebased version also has the issue of messing with the SEC_READONLY check currently present; that should stay, as SEC_READONLY determines where the copied symbol should go, but only matters if we are doing a copy in the first place. This patch hasn't even been compile tested, but I'm 90% confident it works! -- 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/22972] [SPARC] Mixing GOT and GOTDATA_OP relocations can lead to broken binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=22972 --- Comment #2 from James Clarke --- They come from hand-written assembly. Of course that can be modernised, but that doesn’t solve the problem; there are a surprising number of projects out there with hand-written SPARC assembly, and currently LLVM only generates the old relocations. -- 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/22972] New: [SPARC] Mixing GOT and GOTDATA_OP relocations can lead to broken binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=22972 Bug ID: 22972 Summary: [SPARC] Mixing GOT and GOTDATA_OP relocations can lead to broken binaries Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jrtc27 at jrtc27 dot com CC: ebotcazou at gcc dot gnu.org, glaubitz at physik dot fu-berlin.de Target Milestone: --- Target: sparc64-linux-gnu Created attachment 10896 --> https://sourceware.org/bugzilla/attachment.cgi?id=10896=edit Reproduction Currently, if the symbol is defined in the output, non-preemptible and within +/- 4 GiB of the relocation, ld optimises GOTDATA_OP relocations to be GOTDATA, i.e. an add of (sym-_GLOBAL_OFFSET_TABLE_) rather than a load of (_GLOBAL_OFFSET_TABLE_+sym@GOT). After the fix for 22832, when the R_SPARC_GOTDATA_OP (the load) instruction is rewritten, if the symbol is not dynamic, an R_SPARC_NONE is decided upon for the GOT slot (and zero addend) and h->got.offset is tagged with 1. However, if an object file seen later during linking uses the older R_SPARC_GOT22/10 relocations for the same symbol, they will see that h->got.offset is 1 and assume that this means the GOT relocation has been correctly emitted, but in fact it has not; it instead needs an R_SPARC_RELATIVE with the addend equal to the symbol's value. Thus, the R_SPARC_NONE decision must be delayed until all input files have been processed. This bug was discovered thanks to OpenSSL's test suite (https://github.com/openssl/openssl/issues/5586); the attached script demonstrates the problem. -- 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/23030] --gc-sections on ia64 removes needed unwind sections
https://sourceware.org/bugzilla/show_bug.cgi?id=23030 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #5 from James Clarke --- Thanks; please backport this to the 2.30 branch as it also suffers from this. -- 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/15904] ia64, ELF, 'Can't relax br (PCREL21B)' error message on --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=15904 James Clarke changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.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/15904] ia64, ELF, 'Can't relax br (PCREL21B)' error message on --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=15904 James Clarke changed: What|Removed |Added CC||jason.duerstock at gmail dot com, ||jrtc27 at jrtc27 dot com, ||slyfox at inbox dot ru --- Comment #1 from James Clarke --- I just ran into this when compiling qtwebkit, and can confirm that this patch fixed the issue for me. Stephan, if you're still interested in this bug, could you please add a suitable ChangeLog-style commit message and submit this to the mailing list? -- 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/24400] ia64: binutils regression leads to gcc stage2/stage3 compare failure
https://sourceware.org/bugzilla/show_bug.cgi?id=24400 --- Comment #1 from James Clarke --- Not a bug in binutils. GCC's debug info now includes inline entry points, as of GCC r257511, which is currently emitting labels rather than tags due to using the wrong macro, thereby forcing new bundles to start when such a label is in the middle of one. -- 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/27296] ld riscv: Add _fbsd emulations and riscv*-*-freebsd* triples
https://sourceware.org/bugzilla/show_bug.cgi?id=27296 Jessica Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #2 from Jessica Clarke --- This should be closed given discussions about this being intended behaviour. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28398] binutils: ld: KEEP ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=28398 Jessica Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #3 from Jessica Clarke --- 1. That's because you need -Wl,--whole-archive to include all .o files in the .a 2. Don't put a dot in the section names, make them valid C identifiers and use the linker-generated __start_$section/__stop_$section names 3. You will need -Wl,-z,nostart-stop-gc for LLD 13+ because the maintainer decided breaking coding patterns that have worked for decades is fine (binutils also accepts the flag as of 2.37 but does not currently default to the broken behaviour) If you want a BSD-2-Clause-licensed linker set implementation you can grab sys/sys/linker_set.h from FreeBSD and alter it however you like. -- You are receiving this mail because: You are on the CC list for the bug.
