[Bug ld/27491] New: ld: relocation R_X86_64_PC32 against undefined protected symbol `__start_xx' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=27491 Bug ID: 27491 Summary: ld: relocation R_X86_64_PC32 against undefined protected symbol `__start_xx' can not be used when making a shared object Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- % cat x.s .weak __start_xx .weak __stop_xx .global _start _start: movq __start_xx@gotpcrel(%rip), %rdi movq __stop_xx@gotpcrel(%rip), %rsi .section xx,"a",unique,0 .byte 0 .section xx,"a",unique,1 .byte 1 % as x.s -o x.o # With an ld newer than 2021-03-01 % ./ld-new x.o --gc-sections --print-gc-sections -z start-stop-gc -shared ./ld-new: removing unused section 'xx' in file 'x.o' ./ld-new: removing unused section 'xx' in file 'x.o' ./ld-new: x.o: relocation R_X86_64_PC32 against undefined protected symbol `__start_xx' can not be used when making a shared object ./ld-new: final link failed: bad value I suspect GOTPCRELX optimization is performed while it shouldn't. aarch64 ld works without a diagnostic. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27491] ld: relocation R_X86_64_PC32 against undefined protected symbol `__start_xx' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=27491 Fangrui Song changed: What|Removed |Added Target||x86_64-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27493] New: objcopy --weaken-symbol does not weaken undefined symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=27493 Bug ID: 27493 Summary: objcopy --weaken-symbol does not weaken undefined symbols Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- % cat a.s .globl def def: call undef % cc -c a.s % objcopy --weaken-symbol=def --weaken-symbol=undef a.o b.o % readelf -Ws b.o Symbol table '.symtab' contains 7 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT3 3: 0 SECTION LOCAL DEFAULT4 4: 0 SECTION LOCAL DEFAULT5 5: 0 NOTYPE WEAK DEFAULT1 def 6: 0 NOTYPE GLOBAL DEFAULT UND undef --weaken-symbol applies on a defined symbol but not on an undefined symbol. This was originally raised as a behavior difference between objcopy and llvm-objcopy https://bugs.llvm.org/show_bug.cgi?id=49362 . My feeling is that weakening undefined symbols matches the documentation and should be done. It is a behavior change but it unlikely causes any trouble. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #13 from Nick Clifton --- Hi Tom, > > .section.debug_macro.dwo,"e",@progbits > > .value 0x4 # DWARF macro version number I think that this may be a clue. It looks like the assembler is creating version 4 .debug_macro.dwo sections, but the DWARF-5 standard only defines version 5 sections. Ie, the assembler is for a proposed GNU extension to DWARF, rather than for an official DWARF-5 version. I think that this matters because of the following bytes: [This is from the second .debug_macro.dwo section in hello.s, as this is simpler): .value 0x4 <= version .byte 0 <= flags .byte 0x5 .uleb128 0x13 .uleb128 0x2a4 According to my reading of section 6.3.1 there ought to be *two* bytes following the flags, and before the first LEB128 value: "The table starts with a 1-byte count of the defined opcodes, followed by an entry for each of those opcodes. Each entry starts with a 1-byte unsigned opcode number ..." And then only one LEB128 value for each entry: "... followed by unsigned LEB128 encoded number of operands and for each operand there is a single unsigned byte describing the form in which the operand is encoded." So basically the encoding sequence used for v4 .debug_macro.dwo sections is completely different from the encoding for v5 sections. Hence I think that we need to find the specification for this v4 type of section. Do you know where it might be found ? I also suspect that the "version 0" errors that we have been seeing are due to the tools trying to interpret these sections as v5 sections, and so getting very confused. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27486] readelf: Warning: could not find separate debug file 'libc-2.32.so.debug'
https://sourceware.org/bugzilla/show_bug.cgi?id=27486 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi H.J. > [hjl@gnu-cfl-2 cpu-rt-c]$ readelf --dyn-syms /lib64/libc-2.32.so| grep > strchr > I only want to displace dynamic symbols. Why should readelf care the > separate debug file? It cares because there may be information in the separate debug info files that is relevant to the query that is being carried out. Ie in this case there may be dynamic symbols in the debug info files. You can suppress this behaviour though. Either by configuring the binutils with --enable-follow-debug-links=no or by adding the -wN or --debug-dump=no-follow-links options to the readelf command line. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27407] Add --trace-symbols-from-file?
https://sourceware.org/bugzilla/show_bug.cgi?id=27407 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #3 from Nick Clifton --- OK, closing -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27486] readelf: Warning: could not find separate debug file 'libc-2.32.so.debug'
https://sourceware.org/bugzilla/show_bug.cgi?id=27486 --- Comment #3 from H.J. Lu --- (In reply to Nick Clifton from comment #2) > Hi H.J. > > > [hjl@gnu-cfl-2 cpu-rt-c]$ readelf --dyn-syms /lib64/libc-2.32.so| grep > > strchr > > > I only want to displace dynamic symbols. Why should readelf care the > > separate debug file? > > It cares because there may be information in the separate debug info files > that is relevant to the query that is being carried out. Ie in this case > there may be dynamic symbols in the debug info files. The symbol tables shouldn't depend on the separate debug info files. > You can suppress this behaviour though. Either by configuring the binutils > with --enable-follow-debug-links=no or by adding the -wN or > --debug-dump=no-follow-links options to the readelf command line. > The info being asked doesn't exist in the separate debug info files. A patch is posted at https://sourceware.org/pipermail/binutils/2021-February/115568.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27486] readelf: Warning: could not find separate debug file 'libc-2.32.so.debug'
https://sourceware.org/bugzilla/show_bug.cgi?id=27486 --- Comment #4 from Nick Clifton --- (In reply to H.J. Lu from comment #3) > The symbol tables shouldn't depend on the separate debug info files. Ah - but debug info files can contain symbol tables... > The info being asked doesn't exist in the separate debug info files. A patch > is posted at > > https://sourceware.org/pipermail/binutils/2021-February/115568.html I have approved the patch, since I agree that it only makes sense to warn about unresolveable links if the user has explicitly asked to see them. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27486] readelf: Warning: could not find separate debug file 'libc-2.32.so.debug'
https://sourceware.org/bugzilla/show_bug.cgi?id=27486 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ecd65684f542be614adc56321c118d8985d35409 commit ecd65684f542be614adc56321c118d8985d35409 Author: H.J. Lu Date: Mon Mar 1 05:34:34 2021 -0800 Warn for missing separate debug files only if needed We shouldn't warn missing separate debug files when debug info isn't needed. PR binutils/27486 * dwarf.c (load_separate_debug_info): Issue warning only if do_debug_links is set. * testsuite/binutils-all/compress.exp: Run objdump and readelf with missing debug file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #14 from Tom de Vries --- (In reply to Nick Clifton from comment #13) > Hi Tom, > > > > .section.debug_macro.dwo,"e",@progbits > > > .value 0x4 # DWARF macro version number > > I think that this may be a clue. It looks like the assembler is creating > version 4 .debug_macro.dwo sections, but the DWARF-5 standard only defines > version 5 sections. Ie, the assembler is for a proposed GNU extension to > DWARF, rather than for an official DWARF-5 version. > > I think that this matters because of the following bytes: > > [This is from the second .debug_macro.dwo section in hello.s, as this > is simpler): > > .value 0x4 <= version > .byte 0 <= flags > .byte 0x5 > .uleb128 0x13 > .uleb128 0x2a4 > > According to my reading of section 6.3.1 there ought to be *two* bytes > following the flags, and before the first LEB128 value: > > "The table starts with a 1-byte count of the defined opcodes, >followed by an entry for each of those opcodes. Each entry >starts with a 1-byte unsigned opcode number ..." > > And then only one LEB128 value for each entry: > >"... followed by unsigned LEB128 encoded number of operands > and for each operand there is a single unsigned byte > describing the form in which the operand is encoded." > Um, let's regenerate with -dA: ... .section .debug_macro.dwo,"G",@progbits,wm4.stdcpredef.h.19.006d14bbbe0dc07ba9\ b1ce3fdc8e40d3,comdat .Ldebug_macro1: .value 0x4 # DWARF macro version number .byte 0 # Flags: 32-bit .byte 0x5 # Define macro strp .uleb128 0x13 # At line number 19 .uleb128 0x2a4 # The macro: "_STDC_PREDEF_H 1" ... So, I think the header stops after flags, and the actual contents starts at .byte 0x5, which is described by the standard like so: ... Each macro unit starts with a header and is followed by a series of macro information entries or file inclusion entries. Each entry consists of an opcode followed by zero or more operands. Each macro unit ends with an entry containing an opcode of 0. ... So, the opcode is 0x5 (DW_MACRO_define_strp), and the two .uleb128 are the operands of. I think what is throwing your parsing off is that you're using the description of the opcode_operands_table to parse the macro information entries. But there's no opcode_operands_table, because the corresponding flag opcode_operands_table_flag is 0. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #15 from Tom de Vries --- (In reply to Tom de Vries from comment #14) > ... > .section > .debug_macro.dwo,"G",@progbits,wm4.stdcpredef.h.19.006d14bbbe0dc07ba9\ > b1ce3fdc8e40d3,comdat > .Ldebug_macro1: > .value 0x4 # DWARF macro version number > .byte 0 # Flags: 32-bit > .byte 0x5 # Define macro strp > .uleb128 0x13 # At line number 19 > .uleb128 0x2a4 # The macro: "_STDC_PREDEF_H 1" > ... I'm starting to think this is a gcc bug. At "DW_MACRO_define_strp, DW_MACRO_undef_strp" we have: ... A DW_MACRO_define_strp or DW_MACRO_undef_strp entry has two operands. The first operand encodes the source line number of the #define or #undef macro directive. The second operand consists of an offset into a string table contained in the .debug_str section of the object file. The size of the operand is given in the header offset_size_flag field. ... There doesn't seem to be anything that states the line number needs to be a uleb. But the second operand shouldn't be a uleb. Readelf correctly does: ... case DW_MACRO_define_strp: READ_ULEB (lineno, curr, end); SAFE_BYTE_GET_AND_INC (offset, curr, offset_size, end); ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27486] readelf: Warning: could not find separate debug file 'libc-2.32.so.debug'
https://sourceware.org/bugzilla/show_bug.cgi?id=27486 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #16 from Tom de Vries --- (In reply to Tom de Vries from comment #15) > I'm starting to think this is a gcc bug. Filed gcc PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 -- You are receiving this mail because: You are on the CC list for the bug.
GNU strip fails to set sh_link and sh_info on Solaris SPARC64
Hello,
I noticed that GNU strip produced invalid binaries on SPARC 64, the reason is
that bfd/elf64-sparc.c was not updated in
https://sourceware.org/bugzilla/show_bug.cgi?id=19938 issue.
The attached patch just follows Nick Clifton's changes for other architectures.
Note that .SUNW_symtabsort, .SUNW_symtabnsort, and .SUNW_symtlssort sections
refer to .symtab section, therefore, if .symtab is removed, theses sections
should be skipped in copy as well. However, I am not sure how to properly
implement it, maybe use handle_remove_section_option if the number of symbols
is zero?
$ gstrip ./hello
gstrip: ./stxsKVxc: failed to find link section for section 27
gstrip: ./stxsKVxc: failed to find link section for section 27
gstrip: ./stxsKVxc: failed to find link section for section 28
gstrip: ./stxsKVxc: failed to find link section for section 28
$ gstrip -R .SUNW_symtabsort -R .SUNW_symtabnsort hello
Regards,
LiborFrom 123ae61a418614cf00f3cfb46d0a01df42309dea Mon Sep 17 00:00:00 2001
From: Libor Bukata
Date: Mon, 1 Mar 2021 12:08:31 +0100
Subject: [PATCH] GNU strip fails to set sh_link and sh_info on Solaris SPARC64
The patch adds a missing elf64_sparc_copy_solaris_special_section_fields
function that enables to fill sh_link and sh_info fields in .SUNW_* sections.
Note that elf64_sparc_copy_solaris_special_section_fields is empty since
the default handling is currently sufficient for GNU strip command.
This is a followup patch of the following upstream commits:
commit 5522f910cb539905d6adfdceab208ddfa5e84557
Author: Nick Clifton
Date: Fri Apr 29 09:24:42 2016 +0100
Enhance support for copying and stripping Solaris and ARM binaries.
commit 84865015459b4e9e8ac67f9b91617fbd856d5119
Author: Nick Clifton
Date: Thu Apr 14 12:04:09 2016 +0100
Fix copying Solaris binaries with objcopy.
gdb/ChangeLog:
2021-03-01 Libor Bukata
* bfd/elf64-sparc.c: Fix GNU strip on Solaris SPARC64.
---
bfd/elf64-sparc.c | 20
1 file changed, 20 insertions(+)
diff --git a/bfd/elf64-sparc.c b/bfd/elf64-sparc.c
index e162f0d53d1..1d4521dfcae 100644
--- a/bfd/elf64-sparc.c
+++ b/bfd/elf64-sparc.c
@@ -1004,4 +1004,24 @@ const struct elf_size_info elf64_sparc_size_info =
#undef elf_backend_static_tls_alignment
#define elf_backend_static_tls_alignment 16
+#undef elf_backend_strtab_flags
+#define elf_backend_strtab_flags SHF_STRINGS
+
+static bfd_boolean
+elf64_sparc_copy_solaris_special_section_fields (const bfd *ibfd ATTRIBUTE_UNUSED,
+ bfd *obfd ATTRIBUTE_UNUSED,
+ const Elf_Internal_Shdr *isection ATTRIBUTE_UNUSED,
+ Elf_Internal_Shdr *osection ATTRIBUTE_UNUSED)
+{
+ /* PR 19938: FIXME: Need to add code for setting the sh_info
+ and sh_link fields of Solaris specific section types. */
+ return FALSE;
+}
+
+#undef elf_backend_copy_special_section_fields
+#define elf_backend_copy_special_section_fields elf64_sparc_copy_solaris_special_section_fields
+
#include "elf64-target.h"
+
+#undef elf_backend_strtab_flags
+#undef elf_backend_copy_special_section_fields
--
2.26.2
[Bug binutils/27478] [readelf] warning about missing section in separate debug info file
https://sourceware.org/bugzilla/show_bug.cgi?id=27478 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Nick Clifton --- Hi Tom, That warning should now have gone away, tanks to a patch recently committed by H.J. But in general debug info files can contain information that is relevant to the decoding of other sections in the "main" file, even non-debug sections. (For example debug info files often contain symbol tables which are absent from the main file). This is why the automatic following of debug links behaviour was added. The addition is still being debated however and it may very change. For some information please see the thread starting here: https://sourceware.org/pipermail/binutils/2021-February/115310.html and then continuing here: https://sourceware.org/pipermail/binutils/2021-March/115582.html Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64
Hi Libor, I noticed that GNU strip produced invalid binaries on SPARC 64, the reason is that bfd/elf64-sparc.c was not updated in https://sourceware.org/bugzilla/show_bug.cgi?id=19938 issue. The attached patch just follows Nick Clifton's changes for other architectures. Patch approved - please apply. Note that .SUNW_symtabsort, .SUNW_symtabnsort, and .SUNW_symtlssort sections refer to .symtab section, therefore, if .symtab is removed, theses sections should be skipped in copy as well. However, I am not sure how to properly implement it, maybe use handle_remove_section_option if the number of symbols is zero? That should probably work. If you have the time, please could you give it a try. Cheers Nick
[Bug binutils/27484] clang++: objdump: DWARF error: could not find variable specification at offset
https://sourceware.org/bugzilla/show_bug.cgi?id=27484 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Martin, Please could you upload the clang-dwarf.o file ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #17 from Tom de Vries --- (In reply to Tom de Vries from comment #16) > (In reply to Tom de Vries from comment #15) > > I'm starting to think this is a gcc bug. > > Filed gcc PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 OK, so the latest comment there AFAIU states that this will be fixed for dwarf 5, but for dwarf 4 consumers should support reading the uleb128 instead (for a .debug_macro.dwo section, not for a .debug_macro section). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27268] mingw-w64 fails with dwarf5
https://sourceware.org/bugzilla/show_bug.cgi?id=27268 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED CC||nickc at redhat dot com Status|UNCONFIRMED |RESOLVED --- Comment #5 from Nick Clifton --- Hi Hannes, You are right - more section names are needed. So I have extended your patch to add the same names that are in DWARF.sc (and in the same order, just to make cross referencing easier). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27268] mingw-w64 fails with dwarf5
https://sourceware.org/bugzilla/show_bug.cgi?id=27268 --- Comment #4 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=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0 commit ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0 Author: Nick Clifton Date: Mon Mar 1 16:25:06 2021 + Add DWARF-5 section names to PE and PEP linker scripts. PR 27268 * scripttempl/pe.sc: Add DWARF-5 section names. * scripttempl/pep.sc: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27484] clang++: objdump: DWARF error: could not find variable specification at offset
https://sourceware.org/bugzilla/show_bug.cgi?id=27484 --- Comment #3 from Martin Liska --- Created attachment 13272 --> https://sourceware.org/bugzilla/attachment.cgi?id=13272&action=edit object file -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27484] clang++: objdump: DWARF error: could not find variable specification at offset
https://sourceware.org/bugzilla/show_bug.cgi?id=27484 --- Comment #4 from Martin Liska --- > Please could you upload the clang-dwarf.o file ? Sure, done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27268] mingw-w64 fails with dwarf5
https://sourceware.org/bugzilla/show_bug.cgi?id=27268 --- Comment #6 from Hannes Domani --- So this is the same as the patch I submitted here?: https://sourceware.org/pipermail/binutils/2021-February/115434.html Maybe I should have mentioned it here, is this usually done? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27268] mingw-w64 fails with dwarf5
https://sourceware.org/bugzilla/show_bug.cgi?id=27268 --- Comment #7 from Hannes Domani --- Also, what does this mean for the gcc bug linked above, where this problem was first submitted? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19161] GNU ld wrongly garbage collects section referenced via __start_SECTIONNAME
https://sourceware.org/bugzilla/show_bug.cgi?id=19161 H.J. Lu changed: What|Removed |Added Depends on||27495 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=27495 [Bug 27495] -z start_stop_gc isn't compatible with --gc-sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/11133] gc-sections deletes sections with __start/__stop reference
https://sourceware.org/bugzilla/show_bug.cgi?id=11133 H.J. Lu changed: What|Removed |Added Depends on||27495 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=27495 [Bug 27495] -z start_stop_gc isn't compatible with --gc-sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/20022] --gc-sections is broken with __start_ and shared library
https://sourceware.org/bugzilla/show_bug.cgi?id=20022 H.J. Lu changed: What|Removed |Added Depends on||27495 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=27495 [Bug 27495] -z start_stop_gc isn't compatible with --gc-sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19167] --gc-sections is broken with __start_
https://sourceware.org/bugzilla/show_bug.cgi?id=19167 H.J. Lu changed: What|Removed |Added Depends on||27495 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=27495 [Bug 27495] -z start_stop_gc isn't compatible with --gc-sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27495] New: -z start_stop_gc isn't compatible with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=27495
Bug ID: 27495
Summary: -z start_stop_gc isn't compatible with --gc-sections
Product: binutils
Version: 2.37 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
CC: amodra at gmail dot com, i at maskray dot me
Blocks: 11133, 19161, 19167, 20022, 21562
Target Milestone: ---
On Linux/x86-64, with
diff --git a/ld/ldmain.c b/ld/ldmain.c
index 7a3c02aeaa6..3b2ebe168c6 100644
--- a/ld/ldmain.c
+++ b/ld/ldmain.c
@@ -357,7 +357,7 @@ main (int argc, char **argv)
#ifdef DEFAULT_NEW_DTAGS
link_info.new_dtags = DEFAULT_NEW_DTAGS;
#endif
- link_info.start_stop_gc = FALSE;
+ link_info.start_stop_gc = TRUE;
link_info.start_stop_visibility = STV_PROTECTED;
ldfile_add_arch ("");
I got
FAIL: ld-elf/pr21562a
FAIL: ld-elf/pr21562b
FAIL: ld-elf/pr21562c
FAIL: ld-elf/pr21562d
FAIL: ld-elf/pr21562i
FAIL: ld-elf/pr21562j
FAIL: ld-elf/pr21562k
FAIL: ld-elf/pr21562l
FAIL: ld-elf/pr21562m
FAIL: ld-elf/pr21562n
FAIL: --gc-sections with __start_
FAIL: ld-gc/pr19167
FAIL: pr20022
FAIL: --gc-sections with __start_SECTIONNAME
Referenced Bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=11133
[Bug 11133] gc-sections deletes sections with __start/__stop reference
https://sourceware.org/bugzilla/show_bug.cgi?id=19161
[Bug 19161] GNU ld wrongly garbage collects section referenced via
__start_SECTIONNAME
https://sourceware.org/bugzilla/show_bug.cgi?id=19167
[Bug 19167] --gc-sections is broken with __start_
https://sourceware.org/bugzilla/show_bug.cgi?id=20022
[Bug 20022] --gc-sections is broken with __start_ and shared library
https://sourceware.org/bugzilla/show_bug.cgi?id=21562
[Bug 21562] Refs to __start_SCN of non-orphan sections affect --gc-sections
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/21562] Refs to __start_SCN of non-orphan sections affect --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=21562 H.J. Lu changed: What|Removed |Added Depends on||27495 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=27495 [Bug 27495] -z start_stop_gc isn't compatible with --gc-sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27478] [readelf] warning about missing section in separate debug info file
https://sourceware.org/bugzilla/show_bug.cgi?id=27478 Tom de Vries changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Tom de Vries --- (In reply to Nick Clifton from comment #1) > That warning should now have gone away, tanks to a patch recently > committed by H.J. It didn't. Thanks, - Tom -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27495] -z start_stop_gc isn't compatible with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=27495 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Alan Modra --- Every one of these tests has --gc-sections and is testing the behaviour of __start_* or __stop_*. -z start-stop-gc is designed to drop sections that are only kept due to magically defined __start/__stop symbols, so the fact that these tests now fail with undefined references is exactly what you should expect. -z start-stop-gc is *not* an option that you can turn on by default. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19161] GNU ld wrongly garbage collects section referenced via __start_SECTIONNAME
https://sourceware.org/bugzilla/show_bug.cgi?id=19161 Bug 19161 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/21562] Refs to __start_SCN of non-orphan sections affect --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=21562 Bug 21562 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/11133] gc-sections deletes sections with __start/__stop reference
https://sourceware.org/bugzilla/show_bug.cgi?id=11133 Bug 11133 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/20022] --gc-sections is broken with __start_ and shared library
https://sourceware.org/bugzilla/show_bug.cgi?id=20022 Bug 20022 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19167] --gc-sections is broken with __start_
https://sourceware.org/bugzilla/show_bug.cgi?id=19167 Bug 19167 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19161] GNU ld wrongly garbage collects section referenced via __start_SECTIONNAME
https://sourceware.org/bugzilla/show_bug.cgi?id=19161 Bug 19161 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/11133] gc-sections deletes sections with __start/__stop reference
https://sourceware.org/bugzilla/show_bug.cgi?id=11133 Bug 11133 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/21562] Refs to __start_SCN of non-orphan sections affect --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=21562 Bug 21562 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/20022] --gc-sections is broken with __start_ and shared library
https://sourceware.org/bugzilla/show_bug.cgi?id=20022 Bug 20022 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27495] -z start_stop_gc isn't compatible with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=27495 H.J. Lu changed: What|Removed |Added Resolution|NOTABUG |--- Status|RESOLVED|REOPENED --- Comment #2 from H.J. Lu --- So this option generates broken outputs by design. I don't this is a good idea. Instead, LLVM should generate __gc_start/__gc_stop instead of __start/__stop. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19167] --gc-sections is broken with __start_
https://sourceware.org/bugzilla/show_bug.cgi?id=19167 Bug 19167 depends on bug 27495, which changed state. Bug 27495 Summary: -z start_stop_gc isn't compatible with --gc-sections https://sourceware.org/bugzilla/show_bug.cgi?id=27495 What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27497] New: addr2line: JSON output
https://sourceware.org/bugzilla/show_bug.cgi?id=27497 Bug ID: 27497 Summary: addr2line: JSON output Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- I mentioned it in https://sourceware.org/pipermail/binutils/2021-February/115541.html , but a feature request is more explicit. On LLVM land someone is proposing a JSON output format for llvm-symbolizer (similar to addr2line): https://reviews.llvm.org/D96883 This feature request is to bring awareness about cross project coordination:) If both projects want to add the feature, then having a compatible format will be nice. (Personally I don't think JSON output format for llvm-symbolizer is necessary, but I would not get in their way if other reviewers want it.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27495] -z start_stop_gc isn't compatible with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=27495 --- Comment #3 from Fangrui Song --- (In reply to H.J. Lu from comment #2) > FAIL: ld-elf/pr21562a > FAIL: ld-elf/pr21562b Expected. __start_scnfoo references do not retain scnfoo input sections. > FAIL: ld-elf/pr21562c > FAIL: ld-elf/pr21562d Expected. Use KEEP(*(scnfoo)) to mark scnfoo as GC roots. > FAIL: ld-elf/pr21562i > FAIL: ld-elf/pr21562j > FAIL: ld-elf/pr21562k > FAIL: ld-elf/pr21562l > FAIL: ld-elf/pr21562m > FAIL: ld-elf/pr21562n These reuse the other .s files. > So this option generates broken outputs by design. I don't this is a good > idea. I don't think so. I have performed a large scale test internally, everything except Swift and systemd works. > Instead, LLVM should generate __gc_start/__gc_stop instead of __start/__stop. If __start_/__stop_ were broken, creating new magic symbols might be an option. __start_/__stop_ work in 99.9% cases so not sure new symbols need to be invented. bug 27492 tracks the glibc static linking issue related to stdio flushing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27495] -z start_stop_gc isn't compatible with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=27495 H.J. Lu changed: What|Removed |Added Status|REOPENED|NEW --- Comment #4 from H.J. Lu --- (In reply to Fangrui Song from comment #3) > > __start_/__stop_ work in 99.9% cases so not sure new symbols need to be > invented. To you, it is 0.1% case. To other people, it is 100%. We shouldn't do it to other people if there is a choice. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64
Hi Nick,
On 3/1/21 4:00 PM, Nick Clifton wrote:
Hi Libor,
I noticed that GNU strip produced invalid binaries on SPARC 64, the
reason is that bfd/elf64-sparc.c was not updated in
https://urldefense.com/v3/__https://sourceware.org/bugzilla/show_bug.cgi?id=19938__;!!GqivPVa7Brio!LHjGCJnVDPytceZx1EmUuq933MqeYYHre-566VGSbPbdFKi-HjG8enRG0VyslmNuWw$
issue.
The attached patch just follows Nick Clifton's changes for other
architectures.
Patch approved - please apply.
thank you for your approval. How can I obtain a write permission to
binutils repository?
Note that .SUNW_symtabsort, .SUNW_symtabnsort, and .SUNW_symtlssort
sections refer to .symtab section, therefore, if .symtab is removed,
theses sections should be skipped in copy as well. However, I am not
sure how to properly implement it, maybe use
handle_remove_section_option if the number of symbols is zero?
That should probably work. If you have the time, please could you
give it a try.
I tried the following code:
--- binutils-2.35.1/binutils/objcopy.c 2021-03-01 07:54:25.600752820 +
+++ binutils-2.35.1/binutils/objcopy.c 2021-03-01 07:53:48.447749729 +
@@ -2579,6 +2579,9 @@ check_new_section_flags (flagword flags,
return flags;
}
+static void
+handle_remove_section_option (const char *);
+
/* Copy object file IBFD onto OBFD.
Returns TRUE upon success, FALSE otherwise. */
@@ -3258,6 +3261,13 @@ copy_object (bfd *ibfd, bfd *obfd, const
}
bfd_set_symtab (obfd, osympp, symcount);
+ #if defined(sun) || defined(__sun) || defined(__sun__)
+ if (symcount == 0) {
+ handle_remove_section_option(".SUNW_symtabsort");
+ handle_remove_section_option(".SUNW_symtabnsort");
+ handle_remove_section_option(".SUNW_symtlssort");
+ }
+ #endif
/* This has to happen before section positions are set. */
bfd_map_over_sections (ibfd, copy_relocations_in_section, obfd);
Unfortunately the above code does not work for the following reasons:
- sections are already created in that point of code
- symbol filtering requires output sections to be created
- cannot find bfd_remove_section function that could handle it
I verified that the sections can be removed if requested after argument
processing:
--- binutils-2.35.1/binutils/objcopy.c 2021-01-29 15:13:12.464152915 +
+++ binutils-2.35.1/binutils/objcopy.c 2021-01-29 15:12:55.533627345 +
@@ -4748,6 +4748,12 @@ strip_main (int argc, char *argv[])
}
}
+ #if defined(sun) || defined(__sun) || defined(__sun__)
+ handle_remove_section_option(".SUNW_symtabsort");
+ handle_remove_section_option(".SUNW_symtabnsort");
+ handle_remove_section_option(".SUNW_symtlssort");
+ #endif
+
/* If the user has not expressly chosen to merge/not-merge ELF notes
then enable the merging unless we are stripping debug or dwo
info. */
if (! merge_notes_set
However, this code removes the sections unconditionally regardless of
whether .symtab is kept or not. I can image that GNU strip could be
called in two passes: the first pass could remove .symtab and .strtab
sections; the second pass would strip .SUNW_sym*sort sections if .symtab
section was stripped in the first pass. A big disadvantage is that it
introduces double performance overhead... Any ideas?
Thanks,
Libor
Cheers
Nick
