[Bug gprof/2587] Failed to build gprof under gmake patched by Apple.
https://sourceware.org/bugzilla/show_bug.cgi?id=2587 Szabolcs Nagy changed: What|Removed |Added CC||nszabolcs at gmail dot com --- Comment #13 from Szabolcs Nagy --- i see failures on aarch64* too. make[1]: Entering directory `/B/gprof' make[1]: *** No rule to make target `flat_bl.c', needed by `all'. Stop. make[1]: Leaving directory `/B/gprof' make: *** [all-gprof] Error 2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22269] Undefined weak symbols isn't resolved to 0 in static PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=22269 --- Comment #39 from Szabolcs Nagy --- (In reply to Alan Modra from comment #37) > I agree that there shouldn't be relative relocs on anything to do with foo. > But a pattern that matches those but not relative relocs for powerpc64 on > the opd entry for _start is a little tricky. Hmm, let me see what I can do. thanks the test now does show the bug on arm, i'll try to fix that when i get some time. -- 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/22269] Undefined weak symbols isn't resolved to 0 in static PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=22269
Szabolcs Nagy changed:
What|Removed |Added
CC||nszabolcs at gmail dot com
--- Comment #36 from Szabolcs Nagy ---
on arm with -static -pie
extern int foo __attribute ((weak));
int
_start ()
{
if ()
return foo;
}
has a R_*_RELATIVE reloc which is wrong in pie for undef weak syms.
i think the ld-elf/pr22269-1.rd test should reject relative relocs too.
--
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/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=22589 Szabolcs Nagy changed: What|Removed |Added CC||nszabolcs at gmail dot com --- Comment #7 from Szabolcs Nagy --- in position dependent code the most reasonable behaviour is to try to set the symbol address to 0 and if 0 is outside of the range of adrp then report a linker error. in position independent code adrp for weak undefined symbol should be a linker error. -- 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
[Bug admin/23156] build breaks with old makeinfo: gdb/doc/gdb.texinfo:43443: `gdb-add-index man' has no Up field
https://sourceware.org/bugzilla/show_bug.cgi?id=23156 Szabolcs Nagy changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Szabolcs Nagy --- fixed in 51dcdc52bb8d94d213687d7015c3a234e3dd9cf9 on binutils-2_30-branch (only this branch was affected). -- 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 admin/23156] build breaks with old makeinfo: gdb/doc/gdb.texinfo:43443: `gdb-add-index man' has no Up field
https://sourceware.org/bugzilla/show_bug.cgi?id=23156 Szabolcs Nagy changed: What|Removed |Added Component|build |admin Version|8.1 |2.30 Product|gdb |binutils -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 --- Comment #1 from Szabolcs Nagy --- also discussed at https://sourceware.org/ml/binutils/2017-01/msg00429.html -- 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/21086] New: static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086
Bug ID: 21086
Summary: static linking with --dynamic-list adds dynamic
section and interpreter
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nszabolcs at gmail dot com
Target Milestone: ---
i think static linking should work (produce a static
linked executable without any dynamic linker) even
with --dynamic-list, now the produced executable is
broken.
reproducer:
echo 'int main(){}' >a.c
echo '{main;};' >foo.list
gcc -static -Wl,--dynamic-list=foo.list a.c
readelf -l a.out |grep interpreter
[Requesting program interpreter: /lib/ld64.so.1]
(this is on x86_64, but other targets have the same behaviour)
introduced in
https://sourceware.org/ml/binutils/2016-02/msg00251.html
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bf89386a862ace008f0152bca8bddf996d3993c8
--
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/20737] [aarch64] -static -pie linked binary has R_AARCH64_ABS64 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20737 Szabolcs Nagy changed: What|Removed |Added Target||aarch64-*, arm-* --- Comment #1 from Szabolcs Nagy --- it seems 32bit arm is also affected: $ arm-none-linux-gnueabihf-ld -nostdlib -Bstatic -X -marmelf_linux_eabi -pie --no-dynamic-linker a.o b.o $ arm-none-linux-gnueabihf-readelf -r --dyn-sym -W a.out Relocation section '.rel.dyn' at offset 0x134 contains 2 entries: Offset InfoTypeSym. Value Symbol's Name 0001100c 0017 R_ARM_RELATIVE 00011010 0302 R_ARM_ABS3200011014 i Symbol table '.dynsym' contains 4 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0144 0 SECTION LOCAL DEFAULT5 2: 00011010 0 SECTION LOCAL DEFAULT8 3: 00011014 4 OBJECT GLOBAL DEFAULT9 i -- 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/20737] New: [aarch64] -static -pie linked binary has R_AARCH64_ABS64 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20737
Bug ID: 20737
Summary: [aarch64] -static -pie linked binary has
R_AARCH64_ABS64 relocation
Product: binutils
Version: 2.28 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nszabolcs at gmail dot com
Target Milestone: ---
with -static -pie all symbols should be resolved within the executable module,
only R_AARCH64_RELATIVE relocations may remain in the binary (which can be
processed in the startup code).
ld sometimes produces R_AARCH64_ABS64 relocs and exported symbols in the
dynamic symbol table:
$ cat a.c
int i = 0;
int foo(int *);
void _start(){foo();}
$ cat b.c
extern int i;
static int *q =
int foo(int *p){ return p==q; }
$ aarch64-none-linux-gnu-gcc -c -fPIC a.c
$ aarch64-none-linux-gnu-gcc -c -fPIC b.c
$ aarch64-none-linux-gnu-ld -nostdlib -Bstatic -X -EL -maarch64linux -pie
--no-dynamic-linker a.o b.o
$ aarch64-none-linux-gnu-readelf -r --dyn-syms -W a.out
Relocation section '.rela.dyn' at offset 0x1e0 contains 2 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
00010fe0 0403 R_AARCH64_RELATIVE
11008
00011000 00030101 R_AARCH64_ABS6400011008 i +
0
Symbol table '.dynsym' contains 4 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0210 0 SECTION LOCAL DEFAULT5
2: 00011000 0 SECTION LOCAL DEFAULT9
3: 00011008 4 OBJECT GLOBAL DEFAULT 10 i
--
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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 --- Comment #8 from Szabolcs Nagy --- (In reply to Szabolcs Nagy from comment #7) > (order of objects in the archive seems to matter for some reason). that's only because the out-of-bound reldata->hashes[2] entry happens to be 0 with some ordering which works out fine. -- 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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 --- Comment #7 from Szabolcs Nagy --- attached the asm test cases, they are compiled from glibc sources sysdeps/gnu/unwind-resume.c sysdeps/arm/find_exidx.c sysdeps/arm/aeabi_unwind_cpp_pr1.c and an archive of the resulting objects triggers the crash with ld -r --whole-archive (order of objects in the archive seems to matter for some reason). -- 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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 --- Comment #6 from Szabolcs Nagy --- Created attachment 9529 --> https://sourceware.org/bugzilla/attachment.cgi?id=9529=edit testcase asm 3 -- 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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 --- Comment #5 from Szabolcs Nagy --- Created attachment 9528 --> https://sourceware.org/bugzilla/attachment.cgi?id=9528=edit testcase asm 2 -- 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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 --- Comment #4 from Szabolcs Nagy --- Created attachment 9527 --> https://sourceware.org/bugzilla/attachment.cgi?id=9527=edit testcase asm 1 -- 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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 --- Comment #1 from Szabolcs Nagy --- during bfd_elf_final_link: bfd/elflink.c:11409 bfd_elf_final_link first sets reldata->count to 2 bfd/elf32-arm.c:19031 elf32_arm_count_output_relocs counts 3 output relocs bfd/elflink.c:2468 _bfd_elf_link_size_reloc_section allocates 3 entry for reldata->hdr.contents allocates 2 entry for reldata->hash bfd/elf32-arm.c:19336 emit_relocs sets reldata->count to 3 bfd/elflink.c:8406 elf_link_adjust_relocs assumes reldata->count (3) is the size of reldata->hashes so either the hash allocation is incorrect in _bfd_elf_link_size_reloc_section or the relocation counting is wrong. -- 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/20636] New: [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 Bug ID: 20636 Summary: [arm] ld crash when linking glibc unwind code Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: nszabolcs at gmail dot com Target Milestone: --- Created attachment 9522 --> https://sourceware.org/bugzilla/attachment.cgi?id=9522=edit archive of 3 object files from glibc if i cross compile glibc trunk (version bb8081f57f23a3e1b28b1b7104f24d17da9a3d82) from x86_64 to arm then linking libc_pic.a into libc_pic.os crashes ld since binutils commit 5025eb7c0d87b01507116353b5d63b163d7add3d . i attached a reduced archive file that only contains 3 object files from glibc that trigger the crash with $ arm-none-linux-gnueabihf-ld -r -o bug.o --whole-archive libx.a Segmentation fault (core dumped) -- 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/18705] handle extern protected data
https://sourceware.org/bugzilla/show_bug.cgi?id=18705 Szabolcs Nagy nszabolcs at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Szabolcs Nagy nszabolcs at gmail dot com --- fixed in commit 32f573bcb3aaa1c9defcad79dbb5851fcc02ae2d -- 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/18705] handle extern protected data
https://sourceware.org/bugzilla/show_bug.cgi?id=18705 Szabolcs Nagy nszabolcs at gmail dot com changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nszabolcs at gmail dot com -- 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/18705] New: handle extern protected data
https://sourceware.org/bugzilla/show_bug.cgi?id=18705 Bug ID: 18705 Summary: handle extern protected data Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: nszabolcs at gmail dot com Target Milestone: --- Same as bug 17709 for aarch64 and arm, related to glibc bug 17711. _bfd_elf_symbol_refs_local_p should return false for protected visibility data in shared objects, so the main module with copy reloc against it will see the same address. -- 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/18705] handle extern protected data
https://sourceware.org/bugzilla/show_bug.cgi?id=18705 Szabolcs Nagy nszabolcs at gmail dot com changed: What|Removed |Added Target||arm-*-*, aarch64-*-* -- 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
