[Bug ld/23425] New: unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425
Bug ID: 23425
Summary: unresolved symbol diagnostic ends up calling
find_abstract_instance with relocations applied
causing spurious 'DWARF error: invalid abstract
instance DIE ref'
Product: binutils
Version: 2.30
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Backtrace from the 2.31 branch:
#0 _bfd_error_handler (
fmt=0x690150 "DWARF error: invalid abstract instance DIE ref")
at /space/rguenther/src/binutils-gdb/bfd/bfd.c:1177
#1 0x004c6214 in find_abstract_instance (unit=0x7056d8,
orig_info_ptr=0x76df90 "\004> ", attr_ptr=0x7fffcd10, pname=0x770f18,
is_linkage=0x770f14, filename_ptr=0x770f00, linenumber_ptr=0x770f0c)
at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:2843
#2 0x004c6cbe in scan_unit_for_symbols (unit=0x7056d8)
at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:3169
#3 0x004c789f in comp_unit_find_nearest_line (unit=0x7056d8,
addr=4198435, filename_ptr=0x7fffd018, function_ptr=0x7fffce70,
linenumber_ptr=0x7fffd00c, discriminator_ptr=0x0, stash=0x7054a0)
at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:3616
#4 0x004c9975 in _bfd_dwarf2_find_nearest_line (abfd=0x6fe880,
symbols=0x705270, symbol=0x0, section=0x700dd0, offset=35,
filename_ptr=0x7fffd018, functionname_ptr=0x7fffd010,
linenumber_ptr=0x7fffd00c, discriminator_ptr=0x0,
debug_sections=0x68f9a0 , addr_size=4,
pinfo=0x700090) at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:4807
#5 0x00491807 in _bfd_elf_find_nearest_line (abfd=0x6fe880,
symbols=0x705270, section=0x700dd0, offset=35,
filename_ptr=0x7fffd018, functionname_ptr=0x7fffd010,
line_ptr=0x7fffd00c, discriminator_ptr=0x0)
at /space/rguenther/src/binutils-gdb/bfd/elf.c:8752
#6 0x0042574f in vfinfo (fp=0x77bd2080 <_IO_2_1_stderr_>,
fmt=0x555b18 ": undefined reference to `%pT'\n", ap=0x7fffd208,
is_warning=1) at /space/rguenther/src/binutils-gdb/ld/ldmisc.c:350
#7 0x0042643f in einfo (
fmt=0x555b10 "%X%P: %C: undefined reference to `%pT'\n")
at /space/rguenther/src/binutils-gdb/ld/ldmisc.c:626
#8 0x0041fd50 in undefined_symbol (info=0x6ced80 ,
name=0x70506c "_ZNSsC1Ev", abfd=0x6fe880, section=0x700dd0, address=35,
error=1) at /space/rguenther/src/binutils-gdb/ld/ldmain.c:1346
#9 0x0046ad3d in elf_x86_64_relocate_section (output_bfd=0x6e7210,
info=0x6ced80 , input_bfd=0x6fe880, input_section=0x700dd0,
contents=0x701f60 "UH\211", ,
relocs=0x7050f8, local_syms=0x6f32b0, local_sections=0x76dd60)
at /space/rguenther/src/binutils-gdb/bfd/elf64-x86-64.c:2483
The code says it only handles refs within the same file but the guard
for this, a zero die_ref, doesn't work after applying relocations to
.debug_info and this function ends up being called from the unresolved
symbol diagnostic causing a spurious DWARF error to be reported.
/* We only support DW_FORM_ref_addr within the same file, so
any relocations should be resolved already. Check this by
testing for a zero die_ref; There can't be a valid reference
to the header of a .debug_info section.
DW_FORM_ref_addr is an offset relative to .debug_info.
Normally when using the GNU linker this is accomplished by
emitting a symbolic reference to a label, because .debug_info
sections are linked at zero. When there are multiple section
groups containing .debug_info, as there might be in a
relocatable object file, it would be reasonable to assume that
a symbolic reference to a label in any .debug_info section
might be used. Since we lay out multiple .debug_info
sections at non-zero VMAs (see place_sections), and read
them contiguously into stash->info_ptr_memory, that means
the reference is relative to stash->info_ptr_memory. */
size_t total;
info_ptr = unit->stash->info_ptr_memory;
info_ptr_end = unit->stash->info_ptr_end;
total = info_ptr_end - info_ptr;
if (!die_ref || die_ref >= total)
{
_bfd_error_handler
(_("DWARF error: invalid abstract instance DIE ref"));
bfd_set_error (bfd_error_bad_value);
return FALSE;
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 --- Comment #1 from Richard Biener --- Created attachment 11143 --> https://sourceware.org/bugzilla/attachment.cgi?id=11143&action=edit testcase To reproduce do > ./ld-new -o a.out ccELcIbzdebugobjtem cccLlhS9debugobjtem > ccqD9BbN.ltrans0.ltrans.o ./ld-new: warning: cannot find entry symbol _start; defaulting to 00401000 ./ld-new: ./ld-new: DWARF error: invalid abstract instance DIE ref ccqD9BbN.ltrans0.ltrans.o: in function `strerrno(int)': :(.text+0x23): undefined reference to `std::basic_string, std::allocator >::basic_string()' ./ld-new: :(.text+0x3b): undefined reference to `strerrno_s(char*, unsigned long, int)' ./ld-new: :(.text+0x55): undefined reference to `std::string::operator=(char const*)' ./ld-new: :(.text+0x68): undefined reference to `std::string::operator+=(char const*)' ./ld-new: :(.text+0x7d): undefined reference to `std::string::operator=(char const*)' ./ld-new: :(.text+0x8e): undefined reference to `std::basic_string, std::allocator >::~basic_string()' ./ld-new: :(.text+0x99): undefined reference to `_Unwind_Resume' ./ld-new: ccqD9BbN.ltrans0.ltrans.o:(.eh_frame+0x4b): undefined reference to `__gcc_personality_v0' -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 --- Comment #2 from Richard Biener --- A similar issue seems to happen with .debug_str lookups: /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846). ... later undefined reference diagnostic but I do not have a testcase to verify that. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23405] Some inputs may cause objcopy to crash, without being detected by error checking or assertions
https://sourceware.org/bugzilla/show_bug.cgi?id=23405 --- Comment #4 from zhanggen12 at hotmail dot com --- (In reply to Alan Modra from comment #3) > Yes, I see a segfault with 2.30, but don't with 2.31. I don't believe we > should be spending time fixing bugs that are only tickled by fuzzed objects, > on anything but master binutils. > > *** This bug has been marked as a duplicate of bug 22887 *** Hi, Alan. I checked out Binutils official download website http://ftp.gnu.org/gnu/binutils/. 2.31 was uploaded in 2018-7-14. But I submitted bug 23405 in 2018-7-12. And I was told my bug is fixed in 2.31. And I just wanna know, is there any other websites where Binutils 2.31 can be downloaded before I submitted bug 23405? I just cannot understand this logic. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23418] Incorrect xmmword is accepted
https://sourceware.org/bugzilla/show_bug.cgi?id=23418
--- 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=11a322db5c8bc23009e97af30180d6b14d86dbd3
commit 11a322db5c8bc23009e97af30180d6b14d86dbd3
Author: H.J. Lu
Date: Wed Jul 18 05:33:36 2018 -0700
x86: Split vcvtps2{,u}qq and vcvttps2{,u}qq
After
commit 1b54b8d7e4fc8055f9220a5287e8a94d8a65a88d
Author: Jan Beulich
Date: Mon Dec 18 09:36:14 2017 +0100
x86: fold RegXMM/RegYMM/RegZMM into RegSIMD
... qualified by their respective sizes, allowing to drop FirstXmm0 at
the same time.
folded RegXMM, RegYMM and RegZMM into RegSIMD, it's no longer impossible
to distinguish if Xmmword can represent a memory reference when operand
specification contains SIMD register. For example, template operands
specification like these
RegXMM|...|Xmmword|...
and
RegXMM|...
The Xmmword bitfield is always set by RegXMM which is represented by
"RegSIMD|Xmmword". This patch splits each of vcvtps2qq, vcvtps2uqq,
vcvttps2qq and vcvttps2uqq into 2 templates: one template only has
RegXMM source operand and the other only has mempry source operand.
gas/
PR gas/23418
* testsuite/gas/i386/xmmword.s: Add tests for vcvtps2qq,
vcvtps2uqq, vcvttps2qq and vcvttps2uqq.
* testsuite/gas/i386/xmmword.l: Updated.
opcodes/
PR gas/23418
* i386-opc.h (Byte): Update comments.
(Word): Likewise.
(Dword): Likewise.
(Fword): Likewise.
(Qword): Likewise.
(Tbyte): Likewise.
(Xmmword): Likewise.
(Ymmword): Likewise.
(Zmmword): Likewise.
* i386-opc.tbl: Split vcvtps2qq, vcvtps2uqq, vcvttps2qq and
vcvttps2uqq.
* i386-tbl.h: Regenerated.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23426] New: ld manual is inconsistent with reality w.r.t. default --hash-style value
https://sourceware.org/bugzilla/show_bug.cgi?id=23426 Bug ID: 23426 Summary: ld manual is inconsistent with reality w.r.t. default --hash-style value Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: vlad at ispras dot ru Target Milestone: --- This was introduced in 2760f24c4942853eac7b921e4b8843d57a602654 where the default hash style was made configurable. The documentation (ld/ld.texi) should reflect this change. Currenly it says '--hash-style=STYLE' ... The default is 'sysv'. For all platforms and configurations (and this is now false by default for e.g. x86-64 linux). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23405] Some inputs may cause objcopy to crash, without being detected by error checking or assertions
https://sourceware.org/bugzilla/show_bug.cgi?id=23405 --- Comment #5 from H.J. Lu --- (In reply to zhanggen12 from comment #4) > (In reply to Alan Modra from comment #3) > > Yes, I see a segfault with 2.30, but don't with 2.31. I don't believe we > > should be spending time fixing bugs that are only tickled by fuzzed objects, > > on anything but master binutils. > > > > *** This bug has been marked as a duplicate of bug 22887 *** > > Hi, Alan. I checked out Binutils official download website > http://ftp.gnu.org/gnu/binutils/. 2.31 was uploaded in 2018-7-14. But I > submitted bug 23405 in 2018-7-12. And I was told my bug is fixed in 2.31. > And I just wanna know, is there any other websites where Binutils 2.31 can > be downloaded before I submitted bug 23405? I just cannot understand this > logic. You should also test the latest release branch, binutils-2_31-branch, which was created on June 24, 2018. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23418] Incorrect xmmword is accepted
https://sourceware.org/bugzilla/show_bug.cgi?id=23418
--- Comment #6 from cvs-commit at gcc dot gnu.org ---
The binutils-2_31-branch branch has been updated by H.J. Lu
:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=01683b308a016c49418aee27241389bd2560e0f1
commit 01683b308a016c49418aee27241389bd2560e0f1
Author: H.J. Lu
Date: Wed Jul 18 12:34:44 2018 -0700
x86: Split vcvtps2{,u}qq and vcvttps2{,u}qq
After
commit 1b54b8d7e4fc8055f9220a5287e8a94d8a65a88d
Author: Jan Beulich
Date: Mon Dec 18 09:36:14 2017 +0100
x86: fold RegXMM/RegYMM/RegZMM into RegSIMD
... qualified by their respective sizes, allowing to drop FirstXmm0 at
the same time.
folded RegXMM, RegYMM and RegZMM into RegSIMD, it's no longer impossible
to distinguish if Xmmword can represent a memory reference when operand
specification contains SIMD register. For example, template operands
specification like these
RegXMM|...|Xmmword|...
and
RegXMM|...
The Xmmword bitfield is always set by RegXMM which is represented by
"RegSIMD|Xmmword". This patch splits each of vcvtps2qq, vcvtps2uqq,
vcvttps2qq and vcvttps2uqq into 2 templates: one template only has
RegXMM source operand and the other only has mempry source operand.
gas/
PR gas/23418
* testsuite/gas/i386/xmmword.s: Add tests for vcvtps2qq,
vcvtps2uqq, vcvttps2qq and vcvttps2uqq.
* testsuite/gas/i386/xmmword.l: Updated.
opcodes/
PR gas/23418
* i386-opc.h (Byte): Update comments.
(Word): Likewise.
(Dword): Likewise.
(Fword): Likewise.
(Qword): Likewise.
(Tbyte): Likewise.
(Xmmword): Likewise.
(Ymmword): Likewise.
(Zmmword): Likewise.
* i386-opc.tbl: Split vcvtps2qq, vcvtps2uqq, vcvttps2qq and
vcvttps2uqq.
* i386-tbl.h: Regenerated.
(cherry picked from commit 11a322db5c8bc23009e97af30180d6b14d86dbd3)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23418] Incorrect xmmword is accepted
https://sourceware.org/bugzilla/show_bug.cgi?id=23418 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.32 --- Comment #7 from H.J. Lu --- Fixed for 2.32 and 2.31 branch. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 Jon Grant changed: What|Removed |Added CC||jg at jguk dot org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23428] New: ld does not put program headers in a load segment when static linking an executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 Bug ID: 23428 Summary: ld does not put program headers in a load segment when static linking an executable Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: nszabolcs at gmail dot com Target Milestone: --- simple static linking with is broken with 2.31 ld because it does not put program headers into a load section unless there is some other read only loaded section. $ ld --version GNU ld (GNU Binutils) 2.31.1.20180718 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. $ cat t.s .globl _start _start: xor %rdi,%rdi mov $0xe7,%eax syscall $ as -o t.o t.s $ ld -static t.o $ readelf -aW a.out ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x401000 Start of program headers: 64 (bytes into file) Start of section headers: 4320 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 1 Size of section headers: 64 (bytes) Number of section headers: 5 Section header string table index: 4 Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS00401000 001000 0a 00 AX 0 0 1 [ 2] .symtab SYMTAB 001010 90 18 3 2 8 [ 3] .strtab STRTAB 0010a0 19 00 0 0 1 [ 4] .shstrtab STRTAB 0010b9 21 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), l (large), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00401000 0x00401000 0x0a 0x0a R E 0x1000 Section to Segment mapping: Segment Sections... 00 .text There is no dynamic section in this file. There are no relocations in this file. The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported. Symbol table '.symtab' contains 6 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 00401000 0 SECTION LOCAL DEFAULT1 2: 00401000 0 NOTYPE GLOBAL DEFAULT1 _start 3: 00402000 0 NOTYPE GLOBAL DEFAULT1 __bss_start 4: 00402000 0 NOTYPE GLOBAL DEFAULT1 _edata 5: 00402000 0 NOTYPE GLOBAL DEFAULT1 _end No version information found in this file. $ ./a.out $ Note that the program headers (starting at 0x40 + 64) are not in a load segment, so if the executable tries to access it (based on the program header address the kernel passed in auxv) then it will be a runtime fault. (reading program headers is e.g. needed to support tls in static executables) if i add a readonly note section then program headers are correctly loaded: $ ld --build-id -static t.o $ readelf -lW a.out Elf file type is EXEC (Executable file) Entry point 0x401000 There are 3 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x0040 0x0040 0x00010c 0x00010c R 0x1000 LOAD 0x001000 0x00401000 0x00401000 0x0a 0x0a R E 0x1000 NOTE 0xe8 0x004000e8 0x004000e8 0x24 0x24 R 0x4 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id 01 .text 02 .note.gnu.build-id $ with a 2.30 ld, the prog
[Bug ld/23428] ld does not put program headers in a load segment when static linking an executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 Will Dietz changed: What|Removed |Added CC||sourceware at wdtz dot org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23428] ld does not put program headers in a load segment when static linking an executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23261] objcopy doesn't convert REL to RELA relocations when converting from i386 to x86-64.
https://sourceware.org/bugzilla/show_bug.cgi?id=23261 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Severity|normal |enhancement --- Comment #1 from Alan Modra --- I doubt that this feature will ever be implemented. It isn't so easy to translate relocations from one target to another. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23261] objcopy doesn't convert REL to RELA relocations when converting from i386 to x86-64.
https://sourceware.org/bugzilla/show_bug.cgi?id=23261 --- Comment #2 from Stephen Checkoway --- (In reply to Alan Modra from comment #1) > I doubt that this feature will ever be implemented. It isn't so easy to > translate relocations from one target to another. I believe the i386 to x86-64 translation is already happening. The bug is in not turning REL into RELA. I.e., turning an implicit addend into an explicit one. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23428] ld does not put program headers in a load segment when static linking an executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-19 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- pr23428 branch: https://github.com/hjl-tools/simple-linux/tree/pr23428 has a small run-time testcase: [hjl@gnu-tools-1 simple-linux]$ make gcc -g -O0 -fno-asynchronous-unwind-tables -c -o test.o test.c gcc -g -c -o start.o start.S gcc -g -c -o syscall.o syscall.S ld -z separate-code -o test test.o start.o syscall.o ./test; echo $? /bin/sh: line 1: 16441 Segmentation fault (core dumped) ./test 139 [hjl@gnu-tools-1 simple-linux]$ gcc test.o [hjl@gnu-tools-1 simple-linux]$ ./a.out [hjl@gnu-tools-1 simple-linux]$ echo $? 0 [hjl@gnu-tools-1 simple-linux]$ -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 H.J. Lu changed: What|Removed |Added Assignee|unassigned at sourceware dot org |hjl.tools at gmail dot com Target Milestone|--- |2.32 Summary|ld does not put program |ld does not put program |headers in a load segment |headers in a code-only load |when static linking an |segment |executable | -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
