[Bug binutils/31571] strip mangles 64-bit mach-o binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=31571 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.
[Bug binutils/30569] MIPS16 function stub assertion fail for mipsel_24kc_24kf
https://sourceware.org/bugzilla/show_bug.cgi?id=30569 --- Comment #6 from Alan Modra --- Created attachment 15444 --> https://sourceware.org/bugzilla/attachment.cgi?id=15444&action=edit patch 2 of 2 These are against current git master source. Please give them a hammering. I've verified that the patches fix the haproxy build problem, but they should have wider testing on mips, at least a full gcc plus binutils regression test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30569] MIPS16 function stub assertion fail for mipsel_24kc_24kf
https://sourceware.org/bugzilla/show_bug.cgi?id=30569 Alan Modra changed: What|Removed |Added Attachment #15422|0 |1 is obsolete|| --- Comment #5 from Alan Modra --- Created attachment 15443 --> https://sourceware.org/bugzilla/attachment.cgi?id=15443&action=edit patch 1 of 2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30569] MIPS16 function stub assertion fail for mipsel_24kc_24kf
https://sourceware.org/bugzilla/show_bug.cgi?id=30569 --- Comment #4 from Alan Modra --- OK, so I was able to reproduce this problem building from the haproxy-2.6.13 tar file, using make TARGET=linux-glibc CC=mips-linux-gnu-gcc ARCH=mips CPU_CFLAGS="-Os -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -mips16 -minterlink-mips16 -Wl,-z,now -Wl,-z,relro -fno-strict-aliasing -fwrapv -fasynchronous-unwind-tables" V=1 As I guessed, the link stage uses -Wl,--export-dynamic. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503
--- Comment #11 from dave.anglin at bell dot net ---
On 2024-03-28 7:34 p.m., dave.anglin at bell dot net wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31503
>
> --- Comment #10 from dave.anglin at bell dot net ---
> On 2024-03-28 7:20 p.m., amodra at gmail dot com wrote:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=31503
>>
>> --- Comment #9 from Alan Modra ---
>> (In reply to Andreas Schwab from comment #7)
>>> That should use ALIGN(8).
>> ALIGN inside an output section statement doesn't align the section, just the
>> current *relative* value of dot. So the effect is exacly the same as John's
>> expression. They both align zero to a multiple of eight and thus do nothing.
> Okay. I was hoping that the expression would align the value assigned to
> $global$.
>
> This change appears to successfully align .data:
>
> dave@mx3210:~/gnu/binutils/src/ld/scripttempl$ diff -u elf.sc elf32hppa.sc
> --- elf.sc 2024-03-28 21:45:32.560456976 +
> +++ elf32hppa.sc 2024-03-28 22:26:32.625611275 +
> @@ -669,7 +669,7 @@
>
> ${DATA_PLT+${PLT_BEFORE_GOT-${PLT}}}
>
> - .data ${RELOCATING-0} :
> + .data ${RELOCATING-0} ${CREATE_SHLIB-${CREATE_PIE-${RELOCATING+ALIGN(8)}}}
> :
> {
> ${RELOCATING+${DATA_START_SYMBOLS}}
> *(.data${RELOCATING+ .data.* .gnu.linkonce.d.*})
>
> But it causes two testsuite fails:
>
> PASS: Build pr23162b
> FAIL: Build libpr23161a.so
> PASS: Build pr23161a
> FAIL: Build libpr23161b.so
>
> regexp_diff match failure
> regexp "^Relocation section '\.rel(a|)\.dyn' at offset 0x[0-9a-f]+ contains
> [0-9
> ]+ entries:$"
> line "Relocation section '.rela.got' at offset 0x19c contains 3 entries:"
> output is
> Relocation section '.rela.got' at offset 0x19c contains 3 entries:
> Offset Info Type Sym. Value Symbol's Name + Addend
> 1088 0501 R_PARISC_DIR32 1094 __bss_start + 0
> 108c 0301 R_PARISC_DIR32 1094 _edata + 0
> 1090 0401 R_PARISC_DIR32 1094 _end + 0
>
> If this isn't serious, I can just modify the regexp. Otherwise, do you have
> any thoughts
> on how to work around this issue.
Found it. Need to define "GENERATE_COMBRELOC_SCRIPT=yes".
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503
--- Comment #10 from dave.anglin at bell dot net ---
On 2024-03-28 7:20 p.m., amodra at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31503
>
> --- Comment #9 from Alan Modra ---
> (In reply to Andreas Schwab from comment #7)
>> That should use ALIGN(8).
> ALIGN inside an output section statement doesn't align the section, just the
> current *relative* value of dot. So the effect is exacly the same as John's
> expression. They both align zero to a multiple of eight and thus do nothing.
Okay. I was hoping that the expression would align the value assigned to
$global$.
This change appears to successfully align .data:
dave@mx3210:~/gnu/binutils/src/ld/scripttempl$ diff -u elf.sc elf32hppa.sc
--- elf.sc 2024-03-28 21:45:32.560456976 +
+++ elf32hppa.sc 2024-03-28 22:26:32.625611275 +
@@ -669,7 +669,7 @@
${DATA_PLT+${PLT_BEFORE_GOT-${PLT}}}
- .data ${RELOCATING-0} :
+ .data ${RELOCATING-0} ${CREATE_SHLIB-${CREATE_PIE-${RELOCATING+ALIGN(8)}}} :
{
${RELOCATING+${DATA_START_SYMBOLS}}
*(.data${RELOCATING+ .data.* .gnu.linkonce.d.*})
But it causes two testsuite fails:
PASS: Build pr23162b
FAIL: Build libpr23161a.so
PASS: Build pr23161a
FAIL: Build libpr23161b.so
regexp_diff match failure
regexp "^Relocation section '\.rel(a|)\.dyn' at offset 0x[0-9a-f]+ contains
[0-9
]+ entries:$"
line "Relocation section '.rela.got' at offset 0x19c contains 3 entries:"
output is
Relocation section '.rela.got' at offset 0x19c contains 3 entries:
Offset Info Type Sym. Value Symbol's Name + Addend
1088 0501 R_PARISC_DIR32 1094 __bss_start + 0
108c 0301 R_PARISC_DIR32 1094 _edata + 0
1090 0401 R_PARISC_DIR32 1094 _end + 0
If this isn't serious, I can just modify the regexp. Otherwise, do you have
any thoughts
on how to work around this issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503 --- Comment #9 from Alan Modra --- (In reply to Andreas Schwab from comment #7) > That should use ALIGN(8). ALIGN inside an output section statement doesn't align the section, just the current *relative* value of dot. So the effect is exacly the same as John's expression. They both align zero to a multiple of eight and thus do nothing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31571] strip mangles 64-bit mach-o binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=31571 Jubilee Young changed: What|Removed |Added Version|unspecified |2.42 Host||aarch64-apple-darwin Build||aarch64-apple-darwin Target||aarch64-apple-darwin -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31571] New: strip mangles 64-bit mach-o binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=31571 Bug ID: 31571 Summary: strip mangles 64-bit mach-o binaries Product: binutils Version: unspecified Status: UNCONFIRMED Severity: critical Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: workingjubilee at gmail dot com Target Milestone: --- Created attachment 15441 --> https://sourceware.org/bugzilla/attachment.cgi?id=15441&action=edit a mach-o header diff showing 0xFEEDFACF changed to 0xFEEDFACE Hi! Thanks for strip, it's a really great utility! Rust recently switched to using strip by default in release builds since it allows us to ship full debuginfo for our precompiled stdlib on Linux but then strip the binary after linking in the code. And of course on Linux, this means we're usually using the GNU binutils strip! It works pretty well for most Linux distros, so far. There's only one problem: It doesn't seem to work at all on macOS, and rather than merely failing to do anything, it appears to actively mangle the binary. The resulting binaries will be SIGKILLed almost immediately after startup. This issue may be constrained to aarch64 macOS. x86-64 macOS may be unaffected. I have no reports that suggest otherwise, all of them have been on aarch64 macOS. This has been an ongoing issue for some time, however, so I can't be sure. Triggering it is as simple as booting up an aarch64-darwin system, putting the GNU binutils strip first in your $PATH, installing Rust (for this, https://rustup.rs/ is convenient), and then: cargo new --bin helloworld cd helloworld cargo run --release You will see something like: Compiling helloworld v0.1.0 (/some/path/blah/blah) Finished `release` profile [optimized] target(s) in 0.14s Running `target/release/foo` Killed: 9 This is because as-of rust 1.77, it will attempt to automatically strip the binary and then run it. But it actually causes this with any compiler toolchain as far as I can tell, including simple C binaries compiled with gcc or clang. Part of the issue appears to be mangling the header. The green diff on the right is what happens after a binary is mangled by strip. Usually on macOS, this is not a problem, as people appear to usually have llvm-strip in their PATH, but if they get binutils from Nix, Homebrew, or another route, it seems to usually be GNU binutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503 --- Comment #8 from dave.anglin at bell dot net --- I already tried it. It also sometimes fails to align the $global$ address. spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home /dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gn u/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/. libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/ home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-14 /hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/inclu de -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/sys-include -fchecking= 1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -fmessage- length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOUR CE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd c++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc ++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/g cc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/tests uite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/req uirements/exception/generation_prohibited.cc -std=gnu++17 -include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections -L/home/dave/gnu/gc c/objdir/hppa-linux-gnu/libstdc++-v3/src/filesystem/.libs -L/home/dave/gnu/gcc/o bjdir/hppa-linux-gnu/libstdc++-v3/src/experimental/.libs -lm -o ./generation_pro hibited.exe /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): displacement 0x5cc for insn 0x51370002 is not a multiple of 8 (gp 0x161c4) /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): cannot handle R_PARISC_DPREL14R for _ZZN9__gnu_cxx16random_condition8generateEvE9generator /home/dave/opt/gnu/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status compiler exited with status 1 FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc -std=gnu++17 (test for excess errors) Excess errors: /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): displacement 0x5cc for insn 0x51370002 is not a multiple of 8 (gp 0x161c4) /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): cannot handle R_PARISC_DPREL14R for _ZZN9__gnu_cxx16random_condition8generateEvE9generator /home/dave/opt/gnu/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status The gp value is 4-byte aligned (0x161c4). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503 --- Comment #7 from Andreas Schwab --- That should use ALIGN(8). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503
John David Anglin changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #6 from John David Anglin ---
This fails to align $global$ value under all circumstances:
diff --git a/ld/emulparams/hppalinux.sh b/ld/emulparams/hppalinux.sh
index 7892df9130d..f302606360a 100644
--- a/ld/emulparams/hppalinux.sh
+++ b/ld/emulparams/hppalinux.sh
@@ -25,7 +25,7 @@ NOP=0x08000240
START="_start"
OTHER_READONLY_SECTIONS="
.PARISC.unwind ${RELOCATING-0} : { *(.PARISC.unwind) }"
-DATA_START_SYMBOLS='PROVIDE ($global$ = .);'
+DATA_START_SYMBOLS='PROVIDE ($global$ = (. + 7) & ~ 7);'
DATA_PLT=
PLT_BEFORE_GOT=
GENERATE_SHLIB_SCRIPT=yes
Will try aligning .data.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30569] MIPS16 function stub assertion fail for mipsel_24kc_24kf
https://sourceware.org/bugzilla/show_bug.cgi?id=30569 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com Last reconfirmed||2024-03-28 --- Comment #3 from Alan Modra --- The line for the assertion failure doesn't match up with 2.40 sources.. Is the assertion this one? BFD_ASSERT (hmips->need_fn_stub); If so, it seems likely to me that a symbol with fn_stub non-null has become dynamic after being processed by mips_elf_check_symbols, possibly due to the linker being invoked with one of the --export-dynamic options. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31567] New: gas/ld: Implicit addends for non-code sections
https://sourceware.org/bugzilla/show_bug.cgi?id=31567 Bug ID: 31567 Summary: gas/ld: Implicit addends for non-code sections Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- ELF defines two relocation formats, REL and RELA. REL uses implicit addends, saving space compared to RELA's explicit addend field. However, REL is often inadequate for static code relocations because the instruction to be modified (commonly 4 bytes on RISC architectures) limits the available space for the addend. GNU assembler generates RELA static relocations for most ports and generates REL for very few ones (AArch32, BPF, M32R, MIPS o32). However, using RELA can be unnecessarily bulky for data and debug sections where the constraints on addend size don't apply. I propose that we add an assembler option `-Wa,--implicit-addends-for-data` to allow non-code sections to use implicit addends to save space. In a clang -O0 -g -gpubnames build, using REL for non-code sections (sections without the SHF_EXECINSTR flag) decreased relocation size by 27.1% and the .o file size by 6.4%. Using CREL (`clang -Wa,--crel,--implicit-addends-for-data`) decreased the .o file size by 21.6%! ``` |reloc size | .o size -+---+ RELA | 550519056 | 2339938120 REL data | 401209104 | 2190607000 -Wa,--implicit-addends-for-data CREL | 44865612 | 1834284744 -Wa,--crel,--implicit-addends-for-data ``` ``` # https://github.com/MaskRay/llvm-project/tree/demo-crel clang -fuse-ld=lld -Wa,--implicit-addends-for-data a.c -o a ``` The saving is less pronounced in a non-debug -O3 build (2.3% .o file size) due to relatively fewer data relocations. ``` |reloc size | .o size -+---+--- RELA | 28235664 | 136014800 REL data | 25081480 | 132847952 CREL | 3812677 | 111591872 -Wa,--implicit-addends-for-data CREL | 3482387 | 111261704 -Wa,--crel,--implicit-addends-for-data ``` --- Technically, data sections can have static code relocations because assemblers don't reject `.data; call foo`. Since we are adding an opt-in assembler option, we can rely on the user to do the right thing and only use data directives. For a custom section, `sec->use_rela_p` is at a location matching the following stack trace. ``` perform_an_assembly_pass read_a_source_file obj_elf_section change_section subseg_force_new subseg_get bfd_make_section_anyway bfd_make_section_anyway_with_flags bfd_section_init _bfd_elf_new_section_hook ``` _bfd_elf_new_section_hook sets `sec->use_rela_p = bed->default_use_rela_p;` --- The GNU ld support for REL data relocations seems good, but .eh_frame needs to be fixed. ``` # clang is patched with my user branch mentioned by https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf#relleb-for-dynamic-relocations % fclang -Wa,--implicit-addends-for-data a.c b.c -fuse-ld=bfd -o a /usr/bin/ld.bfd: .eh_frame_hdr refers to overlapping FDEs /usr/bin/ld.bfd: final link failed: bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) % fclang -Wa,--implicit-addends-for-data a.c b.c -fuse-ld=bfd -o a -fno-asynchronous-unwind-tables % ./a hello h 0x5633b227e020 0x5633b227e028 % fclang -Wa,--implicit-addends-for-data a.c b.c -fuse-ld=bfd -o a -fno-asynchronous-unwind-tables -static --target=aarch64-linux-gnu % ./a hello h 0x490050 0x490058 ``` -- You are receiving this mail because: You are on the CC list for the bug.
