[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/28143] New: start-stop-gc feature addition broke link with ldscr
From: |
andy at omniosce dot org |
Subject: |
[Bug ld/28143] New: start-stop-gc feature addition broke link with ldscript |
Date: |
Mon, 26 Jul 2021 11:55:26 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=28143
Bug ID: 28143
Summary: start-stop-gc feature addition broke link with
ldscript
Product: binutils
Version: 2.37
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: andy at omniosce dot org
Target Milestone: ---
Updating to binutils 2.37 has broken the build of the boot loader in the
illumos project.
The loader uses linker sets to implement its internal commands, and ld in
binutils 2.37 is stripping the command symbols where it did not before, with no
change in linker options.
The loader is built with an ldscript which contains:
.data :
{
...
__start_set_Xcommand_set = .;
*(set_Xcommand_set)
__stop_set_Xcommand_set = .;
...
}
and the linker is invoked with:
static -T ldscript -N --gc-sections
an example of a symbol which was present with ld from binutils 2.36.1 but is
now stripped:
[65] 0x00063de0 0x00000004 OBJT LOCL D 0 .data
__set_Xcommand_set_sym__cmd_lsdev
additionally, the visibility of the __start and __stop symbols has changed from
protected to default.
- [1943] 0x00063e50 0x00000000 NOTY GLOB P 0 .data
__start_set_Xcommand_set
+ [2232] 0x0005dd80 0x00000000 NOTY GLOB D 0 .data
__start_set_Xcommand_set
Adding KEEP(*(set_Xcommand_set)) to the ldscript stops the symbols from being
stripped, but the visibility change for __start/__stop is still happening.
I used git bisect to narrow down this change in behaviour to the commit which
introduced -z start-stop-gc
(https://sourceware.org/bugzilla/show_bug.cgi?id=27451 )
The commit message for that includes:
(bfd_elf_define_start_stop): Don't modify ldscript_def syms.
and I see a couple of additional tests for ldscript being added here - removing
those restores previous behaviour.
was this change in behaviour around ldscripts intentional or is this a bug?
Note - there's no difference in output with -z start-stop-gc and -z
nostart-stop-gc
Thanks
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/28143] New: start-stop-gc feature addition broke link with ldscript,
andy at omniosce dot org <=