[Bug ld/30791] Do not merge sections with same name and SHF_LINK_ORDER, but different sh_link value

2023-08-29 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=30791

--- Comment #1 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=a422bb9db1a432f6094a186e243717512d50eec9

commit a422bb9db1a432f6094a186e243717512d50eec9
Author: Alan Modra 
Date:   Wed Aug 30 10:45:03 2023 +0930

Re: readelf/objdump: Handle DWARF info with mixed types of range section

PR 30791
* dwarf.c (free_debug_information): Free range_versions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30612] maxpagesize alignment after relro segment takes up space

2023-08-29 Thread i at maskray dot me
https://sourceware.org/bugzilla/show_bug.cgi?id=30612

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #1 from Fangrui Song  ---
Unfortunately, I believe this is nearly infeasible to fix, as long as the
alignment still follows max-page-size, as switching to a two-RW-PT_LOAD layout
in GNU ld is very difficult.

I have a short summary of different design choices:
https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-relro

> GNU ld uses one RW PT_LOAD program header with padding at the start. The 
> first half of the PT_LOAD overlaps with PT_GNU_RELRO. The padding is added so 
> that the end of PT_GNU_RELRO is aligned by max-page-size. (See ld.bfd 
> --verbose output.) Prior to GNU ld 2.39, the end was aligned by 
> common-page-size. GNU ld's one RW PT_LOAD layout makes the alignment increase 
> the file size. max-page-size can be large, such as 65536 for many systems, 
> causing wasted space.
>
> lld utilitizes two RW PT_LOAD program headers: one for RELRO sections and the 
> other for non-RELRO sections. Although this might appear unusual initially, 
> it eliminates the need for alignment padding as seen in GNU ld's layout. I 
> implemented the current layout in 2019 (https://reviews.llvm.org/D58892).
>
> The layout used by mold is similar to that of lld. In mold's case, the end of 
> PT_GNU_RELRO is padded to max-page-size by appending a SHT_NOBITS 
> .relro_padding section. This approach ensures that the last page of 
> PT_GNU_RELRO is protected, regardless of the system page size. However, when 
> the system page size is less than max-page-size, the map from the first RW 
> PT_LOAD is larger than needed.
>
> In my opinion, losing protection for the last page when the system page size 
> is larger than common-page-size is not at all an issue. Protecting .got.plt 
> is the main purpose of -z now. Protecting a small portion of .data.rel.ro 
> doesn't really make the program more secure, given that .data and .bss are so 
> huge and full of attach targets. If users are really anxious, they can set 
> common-page-size to match their system page size.
>
> I am unsure whether lld's hidden assumption about common-page-size <= system 
> page-size is an issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Issue 61822 in oss-fuzz: binutils:fuzz_dwarf: Stack-buffer-overflow in coff_bigobj_swap_aux_in

2023-08-29 Thread sheriffbot via monorail
Updates:
Labels: -restrict-view-commit

Comment #3 on issue 61822 by sheriffbot: binutils:fuzz_dwarf: 
Stack-buffer-overflow in coff_bigobj_swap_aux_in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61822#c3

This bug has been fixed. It has been opened to the public.

- Your friendly Sheriffbot

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.

[Bug gprofng/30491] mttest failed on aarch64 / OL9

2023-08-29 Thread kurt.goebel at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30491

Kurt Goebel  changed:

   What|Removed |Added

   Priority|P2  |P3
 CC||kurt.goebel at oracle dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gprofng/30575] gprofng cannot profile application with clone3()

2023-08-29 Thread kurt.goebel at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30575

Kurt Goebel  changed:

   What|Removed |Added

 CC||kurt.goebel at oracle dot com
   Priority|P2  |P3

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'

2023-08-29 Thread kurt.goebel at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29987

Kurt Goebel  changed:

   What|Removed |Added

 CC||kurt.goebel at oracle dot com
   Priority|P2  |P3

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12

2023-08-29 Thread tromey at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30703

--- Comment #7 from Tom Tromey  ---
Oh never mind, they were here:

https://sourceware.org/pipermail/binutils/2023-March/126468.html

Given the state of BFD doc stuff, I think it's best
to just back out my patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12

2023-08-29 Thread tromey at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30703

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at sourceware dot org

--- Comment #6 from Tom Tromey  ---
(In reply to Jan Beulich from comment #0)
> As was pointed out on the list, commit 8bb23cdbb498 raises the minimum
> makeinfo version required, yet top-level configure.ac continues to be happy
> with 4.7, thus causing the build to fail with (in my case) 4.12

Can you please post the error messages?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gprofng/30808] gprofng tests failed

2023-08-29 Thread vladimir.mezentsev at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30808

Vladimir Mezentsev  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gprofng/30808] New: gprofng tests failed

2023-08-29 Thread vladimir.mezentsev at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30808

Bug ID: 30808
   Summary: gprofng tests failed
   Product: binutils
   Version: 2.42 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gprofng
  Assignee: vladimir.mezentsev at oracle dot com
  Reporter: vladimir.mezentsev at oracle dot com
  Target Milestone: ---

1. 3 tests failed without --enable-shared:
% mkdir x86_64-linux-gnu
% cd x86_64-linux-gnu
% ../configure --target=x86_64-linux-gnu --disable-gdb --disable-sim
% make -j 20
% (cd gprofng/; make check)
 ...
Running
/ws/gprofng-dev-backedup/vmezents/GPROF/binutils-gdb.git/gprofng/testsuite/gprofng.display/display.exp
...
Running
/ws/gprofng-dev-backedup/vmezents/GPROF/binutils-gdb.git/gprofng/testsuite/gprofng.display/gp-archive.exp
...
FAIL: tmpdir/gp-archive
Running
/ws/gprofng-dev-backedup/vmezents/GPROF/binutils-gdb.git/gprofng/testsuite/gprofng.display/gp-collect-app_F.exp
...
FAIL: tmpdir/gp-collect-app_F
Running
/ws/gprofng-dev-backedup/vmezents/GPROF/binutils-gdb.git/gprofng/testsuite/gprofng.display/setpath_map.exp
...
FAIL: tmpdir/setpath_map

=== gprofng Summary ===

# of expected passes3
# of unexpected failures3


2. All tests failed with --enable-shared:
% rm -rf *
% ../configure --target=x86_64-linux-gnu --disable-gdb --disable-sim
--enable-shared
% make -j 20
ERROR: compilation of test program in jsynprog failed
ERROR: compilation of test program in mttest failed
ERROR: compilation of test program in synprog failed
Running
/ws/gprofng-dev-backedup/vmezents/GPROF/binutils-gdb.git/gprofng/testsuite/gprofng.display/gp-archive.exp
...
FAIL: tmpdir/gp-archive
Running
/ws/gprofng-dev-backedup/vmezents/GPROF/binutils-gdb.git/gprofng/testsuite/gprofng.display/gp-collect-app_F.exp
...
FAIL: tmpdir/gp-collect-app_F
Running
/ws/gprofng-dev-backedup/vmezents/GPROF/binutils-gdb.git/gprofng/testsuite/gprofng.display/setpath_map.exp
...
FAIL: tmpdir/setpath_map

=== gprofng Summary ===

# of unexpected failures3
# of unresolved testcases   3

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12

2023-08-29 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30703

Nick Clifton  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |nickc at redhat dot com
 Status|NEW |ASSIGNED

--- Comment #5 from Nick Clifton  ---
Right - I have proposed a patch and asked for comments:

https://sourceware.org/pipermail/binutils/2023-August/129261.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30805] readelf: typos in user messages

2023-08-29 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30805

Nick Clifton  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi Nicolas,

  Thanks for pointing out these typos and providing a fix.

  I have checked in your corrections.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30806] New: CPPFLAGS are missing for bfd/chew, syslex_wrap and sysinfo

2023-08-29 Thread nicolas at debian dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30806

Bug ID: 30806
   Summary: CPPFLAGS are missing for bfd/chew, syslex_wrap and
sysinfo
   Product: binutils
   Version: 2.41
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: nicolas at debian dot org
  Target Milestone: ---

Created attachment 15094
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15094=edit
patch

Hello.
The attached patch fixes this.
It does not refresh {bfd,binutils}/Makefile.in.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30805] readelf: typos in user messages

2023-08-29 Thread nicolas at debian dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30805

nicolas at debian dot org changed:

   What|Removed |Added

   Severity|normal  |minor

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30805] New: readelf: typos in user messages

2023-08-29 Thread nicolas at debian dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30805

Bug ID: 30805
   Summary: readelf: typos in user messages
   Product: binutils
   Version: 2.42 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: nicolas at debian dot org
  Target Milestone: ---

Created attachment 15093
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15093=edit
patch

Hello.
A trivial patch is attached for two typos.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/28231] relocation truncated to fit: R_X86_64_32S against `.text'

2023-08-29 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28231

Jan Beulich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jan Beulich  ---
Thanks for confirming.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/28231] relocation truncated to fit: R_X86_64_32S against `.text'

2023-08-29 Thread ivanhoe at fiscari dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=28231

--- Comment #3 from Markus Fischer  ---
(In reply to Jan Beulich from comment #2)
> Your testcase doesn't match anything in the referenced source; the closest I
> can see there is 
> 
>   "leaq   1f(%%rip),  %%rax"  "\n\t"
> 
> yet the difference (whether or not (%%rip) is appended to 1f) is what I
> would expect to make things work. In fact that code was changed in this very
> way almost three years ago.
> 
> I'm inclined to conclude: Not an issue anymore with the code brought into
> proper shape. Please confirm.

Thank you for pointing that out. With (%%rip) appended to 1f the TK code links
without error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/28441] [RISCV] ld linker relaxation is really slow

2023-08-29 Thread sam at gentoo dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=28441

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.