[Bug binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')
https://sourceware.org/bugzilla/show_bug.cgi?id=29348 --- Comment #7 from Alan Modra --- That looks to be as expected. I wonder if your systems are typedef'ing uint64_t as unsigned long long rather than unsigned long? Preprocessed source for the failing compile should show what underlying type is being used. Can you provide that too? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')
https://sourceware.org/bugzilla/show_bug.cgi?id=29348 --- Comment #6 from Enze Li --- Created attachment 14243 --> https://sourceware.org/bugzilla/attachment.cgi?id=14243&action=edit bfd config.log on OpenBSD7.1 Above attachment was generated when building binutil-gdb on OpenBSD7.1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')
https://sourceware.org/bugzilla/show_bug.cgi?id=29348 --- Comment #5 from Alan Modra --- Can you please attach bfd/config.log from one of the failing builds? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/19063] objcopy does not set Time/Date field for created pei-x86-64 file
https://sourceware.org/bugzilla/show_bug.cgi?id=19063 Alan Modra changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #4 from Alan Modra --- A feature, not a bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/19109] Cannot configure default flag_compress_debug
https://sourceware.org/bugzilla/show_bug.cgi?id=19109 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #39 from Alan Modra --- . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19805] visibility=hidden and .a fails
https://sourceware.org/bugzilla/show_bug.cgi?id=19805 Alan Modra changed: What|Removed |Added Resolution|--- |OBSOLETE Status|WAITING |RESOLVED --- Comment #2 from Alan Modra --- . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/18739] objdump incorrectly disassembles 'movnti' as using 'QWORD PTR'
https://sourceware.org/bugzilla/show_bug.cgi?id=18739 Alan Modra changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |OBSOLETE --- Comment #3 from Alan Modra --- This has been fixed. There is no way anyone should expect backports to ancient versions of binutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/18616] oprofile fails with "BFD: Dwarf Error: found dwarf version '64617', this reader only handles version 2, 3 and 4 information"
https://sourceware.org/bugzilla/show_bug.cgi?id=18616 Alan Modra changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |OBSOLETE --- Comment #11 from Alan Modra --- Yes, this must be an oprofile issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18414] TOC optimization bug (ignoring data deps on addis/ld -> nop/ld opt)
https://sourceware.org/bugzilla/show_bug.cgi?id=18414 Alan Modra changed: What|Removed |Added Status|REOPENED|RESOLVED Target||powerpc64-linux Resolution|--- |OBSOLETE --- Comment #7 from Alan Modra --- Closing since we already have a work-around (--no-toc-optimize) for ancient object files, and compilers since mid-2015 work with the ld optimisation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16934] gc-sections fails to remove unused C++ member functions
https://sourceware.org/bugzilla/show_bug.cgi?id=16934 Alan Modra changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #8 from Alan Modra --- What you'd need is some way for the linker to recognise that references from vtables should not be followed for the purpose of marking sections against garbage collection, and some way of marking the functions called at their call sites. The former is easy enough, the latter is impossible. The linker can't know the function called, by the very nature of virtual functions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)
https://sourceware.org/bugzilla/show_bug.cgi?id=29389
--- Comment #7 from Luca Bacci ---
Thanks, Alan!
I'm going to make a bundle containing all the required object files, will
attach it very soon.
Right now I have just tried debugging this issue in GDB a bit. What I could
find is that when the warning "local symbol `0' has no section" is output by
coff_classify_symbol (bfd *abfd, struct internal_syment *syment), syment points
to freed memory:
Thread 1 hit Breakpoint 1, coff_classify_symbol (abfd=0x1a32e152710,
syment=0x23121ff2f0) at ../../binutils-gdb/bfd/coffcode.h:5038
5038 _bfd_error_handler
(gdb) bt
#0 coff_classify_symbol (abfd=0x1a32e152710, syment=0x23121ff2f0)
at ../../binutils-gdb/bfd/coffcode.h:5038
#1 0x7ff6eda466a6 in _bfd_coff_link_input_bfd (flaginfo=0x23121ff700,
input_bfd=0x1a32e152710) at ../../binutils-gdb/bfd/cofflink.c:1446
#2 0x7ff6eda44ed8 in _bfd_coff_final_link (abfd=0x1a327bc62a0,
info=0x7ff6edd07880 ) at ../../binutils-gdb/bfd/cofflink.c:868
#3 0x7ff6ed9e41ed in ldwrite () at ../../binutils-gdb/ld/ldwrite.c:545
#4 0x7ff6ed9e0b7b in main (argc=79, argv=0x1a326035890)
at ../../binutils-gdb/ld/ldmain.c:513
(gdb) p *abfd
$1 = {filename = 0x1a32e13ac50 "libgobject_2_0_0_dll_d000431.o",
xvec = 0x7ff6edbcf220 , iostream = 0x0,
iovec = 0x7ff6edbb6280 , lru_prev = 0x0, lru_next = 0x0,
where = 0, mtime = 0, id = 2121, flags = 32825, format = bfd_object,
direction = read_direction, cacheable = 0, target_defaulted = 0,
opened_once = 0, mtime_set = 0, no_export = 0, output_has_begun = 0,
has_armap = 0, is_thin_archive = 0, no_element_cache = 0,
selective_search = 0, is_linker_output = 0, is_linker_input = 1,
plugin_format = bfd_plugin_unknown, lto_output = 0, lto_slim_object = 0,
read_only = 0, plugin_dummy_bfd = 0x0, origin = 72736,
proxy_origin = 72736, section_htab = {table = 0x1a32e1548a0,
newfunc = 0x7ff6eda26cfe ,
memory = 0x1a32d75c0d0, size = 4051, count = 5, entsize = 304,
frozen = 0}, sections = 0x1a32e1538a8, section_last = 0x1a32e153d68,
section_count = 5, archive_plugin_fd = -1,
archive_plugin_fd_open_count = 0, archive_pass = 0, alloc_size = 6561,
start_address = 0, outsymbols = 0x1a9ae80, symcount = 8,
dynsymcount = 0, arch_info = 0x7ff6edbe9040 , size = 0,
arelt_data = 0x1a32d75bfd0, my_archive = 0x1a32d75bd20, archive_next = 0x0,
archive_head = 0x0, nested_archives = 0x0, link = {next = 0x1a32e12ff80,
hash = 0x1a32e12ff80}, tdata = {aout_data = 0x1a32e13ac78,
aout_ar_data = 0x1a32e13ac78, coff_obj_data = 0x1a32e13ac78,
pe_obj_data = 0x1a32e13ac78, xcoff_obj_data = 0x1a32e13ac78,
ecoff_obj_data = 0x1a32e13ac78, srec_data = 0x1a32e13ac78,
verilog_data = 0x1a32e13ac78, ihex_data = 0x1a32e13ac78,
tekhex_data = 0x1a32e13ac78, elf_obj_data = 0x1a32e13ac78,
mmo_data = 0x1a32e13ac78, sun_core_data = 0x1a32e13ac78,
sco5_core_data = 0x1a32e13ac78, trad_core_data = 0x1a32e13ac78,
som_data = 0x1a32e13ac78, hpux_core_data = 0x1a32e13ac78,
hppabsd_core_data = 0x1a32e13ac78, sgi_core_data = 0x1a32e13ac78,
lynx_core_data = 0x1a32e13ac78, osf_core_data = 0x1a32e13ac78,
cisco_core_data = 0x1a32e13ac78, versados_data = 0x1a32e13ac78,
netbsd_core_data = 0x1a32e13ac78, mach_o_data = 0x1a32e13ac78,
mach_o_fat_data = 0x1a32e13ac78, plugin_data = 0x1a32e13ac78,
pef_data = 0x1a32e13ac78, pef_xlib_data = 0x1a32e13ac78,
sym_data = 0x1a32e13ac78, any = 0x1a32e13ac78}, usrdata = 0x1a32e15ccf0,
memory = 0x1a32d75bed0, build_id = 0x0}
(gdb) p *syment
$2 = {_n = {_n_name = "0\001\000\000\000\000\000", _n_n = {_n_zeroes = 304,
_n_offset = 13451671603782742029}, _n_nptr = {
0x130 ,
0xbaadf00dbaadf00d }}, n_value = 1, n_scnum = 0, n_flags = 61453, n_type =
49200,
n_sclass = 46 '.', n_numaux = 105 'i'}
(gdb)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/16804] gold rejects kernel linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=16804 Alan Modra changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #10 from Alan Modra --- Closing as per comment #8. GNU ld script syntax is ambiguous in places, requiring back-tracking. Is that expression you have for fill 0x90909090 / DISCARD / , or is it just 0x90909090? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/16723] Excessive memory usage
https://sourceware.org/bugzilla/show_bug.cgi?id=16723 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #5 from Alan Modra --- . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/16336] objcopy generates wrong ELF program headers
https://sourceware.org/bugzilla/show_bug.cgi?id=16336 Alan Modra changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alan Modra --- This one was fixed with the pr20659 patch. Vasilis, your patch was good and should have been committed back in 2013. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/16433] objdump -l reports wrong line numbers
https://sourceware.org/bugzilla/show_bug.cgi?id=16433 Alan Modra changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from Alan Modra --- . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/16006] Assertion failure in operand at ../../gas/expr.c line 1364.
https://sourceware.org/bugzilla/show_bug.cgi?id=16006 Alan Modra changed: What|Removed |Added Resolution|--- |OBSOLETE Status|WAITING |RESOLVED --- Comment #2 from Alan Modra --- No answer to Nick's question. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16005] [avr] Linker crash on a particular instruction sequence with --relax
https://sourceware.org/bugzilla/show_bug.cgi?id=16005 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=10948fb9fd66c029d59c97e04556ab827076336c commit 10948fb9fd66c029d59c97e04556ab827076336c Author: Alan Modra Date: Fri Jul 29 22:35:13 2022 +0930 Re: PR16005, avr linker crash on a particular instruction sequence with --relax The last patch wasn't so clever. The contents in fact have already been read, just not cached where relax_delete_bytes expects them. relax_delete_bytes also modifies relocs and syms, so they should be cached too. PR 16005 * elf32-avr.c (elf32_avr_relax_delete_bytes): Revert last change. (elf32_avr_relax_section): Cache contents, relocs and syms before calling relax_delete_bytes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29342] RISC-V 32: disassembly mishandles negative symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29342 --- Comment #4 from Tsukasa OI --- Posted a patchset: https://sourceware.org/pipermail/binutils/2022-July/122084.html In my environment, disassembler dumps of your ELF file (highsym.elf) and self-compiled version seem fixed. $ # binutils configuration (partial): --target=riscv64-unknown-elf --enable-multilib $ riscv64-unknown-elf-as -march=rv32i -o highsym.o highsym.s $ riscv64-unknown-elf-ld -m elf32lriscv -o highsym.elf highsym.o $ riscv64-unknown-elf-objdump -d highsym.elf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')
https://sourceware.org/bugzilla/show_bug.cgi?id=29348 --- Comment #4 from Enze Li --- It also appears on openbsd7.1 when building with following command, $ ./configure --prefix=/home/lee/dev/binutils-gdb/build/ $ gmake CC archive.lo archive.c:195:56: error: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long') [-Werror,-Wformat] snprintf (buf, sizeof (buf), "%-10" BFD_VMA_FMT "u", size); ^~~~ %-10llu archive.c:517:52: error: format specifies type 'unsigned long *' but the argument has type 'bfd_size_type *' (aka 'unsigned long long *') [-Werror,-Wformat] scan = sscanf (hdr.ar_size, "%" BFD_VMA_FMT "u", &parsed_size); ~ ^~~~ %llu 2 errors generated. gmake[4]: *** [Makefile:1752: archive.lo] Error 1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Nick Clifton --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The binutils-2_39-branch branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c87bc94762a0f5c5960c69278a68c7d60ca2c0c9 commit c87bc94762a0f5c5960c69278a68c7d60ca2c0c9 Author: Nick Clifton Date: Fri Jul 29 13:00:09 2022 +0100 Stop the linker from complaining about unrecognized DW_FORM_rnglistx and DW_FORM_loclistx attribute formats. PR 29424 * dwarf2.c (read_attribute_value): Handle DW_FORM_rnglistx and DW_FORM_loclistx. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b44cfc5de139d7e2410e91846df0f0164d663d0b commit b44cfc5de139d7e2410e91846df0f0164d663d0b Author: Nick Clifton Date: Fri Jul 29 12:58:10 2022 +0100 Stop the linker from complaining about unrecognised DW_FORM-rnglistx and DW_FORM_loclistx format attributes. PR 29424 * dwarf2.c (read_attribute_value): Handle DW_FORM_rnglistx and DW_FORM_loclistx. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 --- Comment #5 from Rainer Orth --- > --- Comment #4 from Rainer Orth --- > I've just spotchecked ld 2.38.90 with that patch included with my > testcase: the link worked fine (or rather failed as expected due to the > missing __atomic_* symbols, but without the DWARF error). I'm now > running a full LLVM main build with that ld on > sparc64-unknown-linux-gnu. Will take a couple of hours, though... The build just completed without any issues. Thanks again. Rainer -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 --- Comment #4 from Rainer Orth --- > --- Comment #2 from Nick Clifton --- Hi Nick, > Unfortunately the reproducer fails for me due to lots of missing system > libraries. Not surprising really given that I was running the test on an > x86_64 linux box... no wonder indeed. That's why I mentioned gcc202 ;-) > Please could you try out the patch I am about to upload. It does not do > much > more than ignore the form, but it may be enough in this particular case. (I > believe that the linker is only parsing the DWARF information so that it can > generate an error message about the missing symbols, so I am hoping that not > decoding the range information will not be a big problem). I've just spotchecked ld 2.38.90 with that patch included with my testcase: the link worked fine (or rather failed as expected due to the missing __atomic_* symbols, but without the DWARF error). I'm now running a full LLVM main build with that ld on sparc64-unknown-linux-gnu. Will take a couple of hours, though... Thanks. Rainer -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16005] [avr] Linker crash on a particular instruction sequence with --relax
https://sourceware.org/bugzilla/show_bug.cgi?id=16005 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.40 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Alan Modra --- Fixed for 2.40 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16005] [avr] Linker crash on a particular instruction sequence with --relax
https://sourceware.org/bugzilla/show_bug.cgi?id=16005 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b875e9c93df9f30efb34a75b9379490c03ec4d4b commit b875e9c93df9f30efb34a75b9379490c03ec4d4b Author: Alan Modra Date: Fri Jul 29 16:52:52 2022 +0930 PR16005, avr linker crash on a particular instruction sequence with --relax It's possible for relax_delete_bytes to be called with section contents NULL, as demonstrated by the testcase in this PR. PR 16005 * elf32-avr.c (elf32_avr_relax_delete_bytes): Get section contents if not already available. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 --- Comment #20 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jan Beulich : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c1723a8118f0d02b01a061095f48e75264b2ca4f commit c1723a8118f0d02b01a061095f48e75264b2ca4f Author: Jan Beulich Date: Fri Jul 29 09:26:47 2022 +0200 Arm64: re-work PR gas/27217 fix The original approach has resulted in anomalies when . is involved in an operand of one of the affected insns. We cannot leave . unresolved, or else it'll be resolved at the end of assembly, then pointing to the address of a section rather than at the insn of interest. Undo part of the original change and instead check whether a relocation cannot be omitted in md_apply_fix(). By resolving the expressions again, equates (see the adjustment of the respective testcase) will now be evaluated, and hence relocations against absolute addresses be emitted. This ought to be okay as long as the equates aren't global (and hence can't be overridden). If a need for such arises, quite likely the only way to address this would be to invent yet another expression evaluation mode, leaving everything _except_ . un-evaluated. There's a further anomaly in how transitive equates are handled. In .set x, 0x12345678 .eqv bar, x foo: adrpx0, x add x0, x0, :lo12:x adrpx0, bar add x0, x0, :lo12:bar the first two relocations are now against *ABS*:0x12345678 (as said above), whereas the latter two relocations would be against x. (Before the change here, the first two relocations are against x and the latter two against bar.) But this is an issue seen elsewhere as well, and would likely require adjustments in the target-independent parts of the assembler instead of trying to hack around this for every target. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED URL||https://sourceware.org/pipe ||rmail/binutils/2022-July/12 ||2057.html Target Milestone|--- |2.39 Assignee|unassigned at sourceware dot org |ro at gcc dot gnu.org Status|REOPENED|RESOLVED --- Comment #10 from Rainer Orth --- Fully fixed for binutils 2.39. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 --- Comment #9 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Rainer Orth : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b80b72c06c29d257b60b4002bd9d6c40dec94ec9 commit b80b72c06c29d257b60b4002bd9d6c40dec94ec9 Author: Rainer Orth Date: Fri Jul 29 09:06:40 2022 +0200 ld: Extend ac_default_ld_warn_rwx_segments to all SPARC targets [PR29411] As discussed in PR ld/29411, the ld warning [...] has a LOAD segment with RWX permissions needs to be disabled on all SPARC targets, not just Solaris/SPARC: the .plt section is required to be RWX by the 32-bit SPARC ELF psABI and the 64-bit SPARC Compliance Definition 2.4.1. Given that ld only supports SPARC ELF targets, this patch implements this. Tested on sparc64-unknown-linux-gnu and sparc-sun-solaris2.11. 2022-07-28 Rainer Orth ld: PR ld/29411 * configure.tgt (ac_default_ld_warn_rwx_segments): Extend to all sparc targets. Expand comment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The binutils-2_39-branch branch has been updated by Rainer Orth : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4b596a7719bfa1bcb8781f59faba66a20c4ab2da commit 4b596a7719bfa1bcb8781f59faba66a20c4ab2da Author: Rainer Orth Date: Fri Jul 29 09:04:59 2022 +0200 ld: Extend ac_default_ld_warn_rwx_segments to all SPARC targets [PR29411] As discussed in PR ld/29411, the ld warning [...] has a LOAD segment with RWX permissions needs to be disabled on all SPARC targets, not just Solaris/SPARC: the .plt section is required to be RWX by the 32-bit SPARC ELF psABI and the 64-bit SPARC Compliance Definition 2.4.1. Given that ld only supports SPARC ELF targets, this patch implements this. Tested on sparc64-unknown-linux-gnu and sparc-sun-solaris2.11. 2022-07-28 Rainer Orth ld: PR ld/29411 * configure.tgt (ac_default_ld_warn_rwx_segments): Extend to all sparc targets. Expand comment. -- You are receiving this mail because: You are on the CC list for the bug.
