[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions

2022-07-29 Thread cvs-commit at gcc dot gnu.org
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.


[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions

2022-07-29 Thread cvs-commit at gcc dot gnu.org
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

2022-07-29 Thread ro at gcc dot gnu.org
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 gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.

2022-07-29 Thread cvs-commit at gcc dot gnu.org
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/16005] [avr] Linker crash on a particular instruction sequence with --relax

2022-07-29 Thread cvs-commit at gcc dot gnu.org
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 ld/16005] [avr] Linker crash on a particular instruction sequence with --relax

2022-07-29 Thread amodra at gmail dot com
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/29424] ld chokes on DW_FORM_rnglistx

2022-07-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE
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/29424] ld chokes on DW_FORM_rnglistx

2022-07-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE
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

2022-07-29 Thread cvs-commit at gcc dot gnu.org
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

2022-07-29 Thread cvs-commit at gcc dot gnu.org
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

2022-07-29 Thread nickc at redhat dot com
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 binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')

2022-07-29 Thread lienze at sourceware dot org
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 binutils/29342] RISC-V 32: disassembly mishandles negative symbols

2022-07-29 Thread research_trasio at irq dot a4lg.com
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 ld/16005] [avr] Linker crash on a particular instruction sequence with --relax

2022-07-29 Thread cvs-commit at gcc dot gnu.org
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 gas/16006] Assertion failure in operand at ../../gas/expr.c line 1364.

2022-07-29 Thread amodra at gmail dot com
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 binutils/16433] objdump -l reports wrong line numbers

2022-07-29 Thread amodra at gmail dot com
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 binutils/16336] objcopy generates wrong ELF program headers

2022-07-29 Thread amodra at gmail dot com
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/16723] Excessive memory usage

2022-07-29 Thread amodra at gmail dot com
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 gold/16804] gold rejects kernel linker script

2022-07-29 Thread amodra at gmail dot com
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/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)

2022-07-29 Thread luca.bacci at outlook dot com
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 ld/16934] gc-sections fails to remove unused C++ member functions

2022-07-29 Thread amodra at gmail dot com
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 ld/18414] TOC optimization bug (ignoring data deps on addis/ld -> nop/ld opt)

2022-07-29 Thread amodra at gmail dot com
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 binutils/18616] oprofile fails with "BFD: Dwarf Error: found dwarf version '64617', this reader only handles version 2, 3 and 4 information"

2022-07-29 Thread amodra at gmail dot com
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 binutils/18739] objdump incorrectly disassembles 'movnti' as using 'QWORD PTR'

2022-07-29 Thread amodra at gmail dot com
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 ld/19805] visibility=hidden and .a fails

2022-07-29 Thread amodra at gmail dot com
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 gas/19109] Cannot configure default flag_compress_debug

2022-07-29 Thread amodra at gmail dot com
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 binutils/19063] objcopy does not set Time/Date field for created pei-x86-64 file

2022-07-29 Thread amodra at gmail dot com
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 binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')

2022-07-29 Thread amodra at gmail dot com
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/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')

2022-07-29 Thread lienze at sourceware dot org
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')

2022-07-29 Thread amodra at gmail dot com
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.