[Bug ld/6468] New: ld: --export-dynamic fails if no undefined symbols
If there are no undefined symbols then there is no Dynamic section, no DT_SYMTAB, and no DT_HASH/DT_GNU_HASH; and --export-dynamic fails silently. So there is no way to have a module (ET_EXEC or ET_DYN) that has no undefined symbols, yet exports some of its own symbols for use by other modules. Steps to Reproduce: 1. cat <export.S _start: .globl _start movl foo,%ebx movl $1,%eax int $0x80 .data foo: .globl foo .int 42 EOF 2. gcc -o export -nostartfiles -nostdlib -Wl,--export-dynamic export.S 3. readelf --all export | grep -i dynamic Actual results: There is no dynamic section in this file. Expected results: Dynamic section at offset 0x contains .. entries: [This bug was originally reported in http://bugzilla.redhat.com/show_bug.cgi?id=444628 and is fowarded here at the suggestion of a maintainer.] -- Summary: ld: --export-dynamic fails if no undefined symbols Product: binutils Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: jreiser at BitWagon dot com CC: bug-binutils at gnu dot org GCC target triplet: i686-pc-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=6468 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6468] ld: --export-dynamic fails if no undefined symbols
--- Additional Comments From jreiser at BitWagon dot com 2008-04-29 18:54 --- Subject: Re: ld: --export-dynamic fails if no undefined symbols drow at false dot org wrote: > --- Additional Comments From drow at false dot org 2008-04-29 18:14 > --- > Subject: Re: New: ld: --export-dynamic fails if no undefined > symbols > > On Tue, Apr 29, 2008 at 05:59:42PM -, jreiser at BitWagon dot com wrote: > >>If there are no undefined symbols then there is no Dynamic section, no >>DT_SYMTAB, and no DT_HASH/DT_GNU_HASH; and --export-dynamic fails silently. >>So >>there is no way to have a module (ET_EXEC or ET_DYN) that has no undefined >>symbols, yet exports some of its own symbols for use by other modules. > > > I don't think this is true for ET_DYN. Have you tested that? It's > not related to undefined symbols; it's caused by not linking an > ET_EXEC against any shared libraries. Yes, adding "-shared" to the command line does give an ET_DYN module with no undefined symbols that does have a Dynamic section and DT_GNU_HASH (or DT_HASH.) But it also has DT_TEXTREL (in this case, or if any actual non-PIC code) and I wish to avoid that. I suppose I could build the module as ET_DYN with specified .p_vaddr, then use a binary editor to change the .e_type to ET_EXEC, and elide the DT_TEXTREL from the Dynamic section; then use objcopy to remove relocation sections. [Did I cover everything that should be changd? ;-)] > This is solved by the --force-dynamic option in the VxWorks port of > ld. The feature was not desired for other targets so the option is > restricted to VxWorks. It seems to me that the ability to construct a symbol table (and associated support) for some runtime global symbols should be an independent feature of ld. Some commandline parameters might force its use, and some uses might omit the table by default, but not being able to force the table is an omission. What was the specific objection to --force-dynamic on non-VxWorks? -- http://sourceware.org/bugzilla/show_bug.cgi?id=6468 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6468] ld: --export-dynamic fails if no undefined symbols
--- Additional Comments From jreiser at BitWagon dot com 2008-04-29 20:46 --- Subject: Re: ld: --export-dynamic fails if no undefined symbols drow at false dot org wrote: > --- Additional Comments From drow at false dot org 2008-04-29 19:48 > --- > Subject: Re: ld: --export-dynamic fails if no undefined > symbols > > On Tue, Apr 29, 2008 at 06:54:37PM -, jreiser at BitWagon dot com wrote: > >>[Did I cover everything that should be changd? ;-)] > Well, you'd also need a PT_INTERP. Probably more. The executable has no undefined symbols (.e_entry receives control), and in particular it needs no PT_INTERP. >>What was the specific objection to --force-dynamic on non-VxWorks? > I don't remember, but I'm sure you can find it in the list archives. http://sourceware.org/ml/binutils/2006-03/msg00020.html "Add --force-dynamic flag to VxWorks targets" is the software itself, but I could find no indication of objections by non-VxWorks targets. I saw just 16 matches to a search for "--force-dynamic" [_with_ quotation marks: try not to ignore punctuation] and none had any discussion about non-VxWorks targets, or including or excluding the ability to force a Dynamic section. I'd like to separate mechanism from policy, so that non-traditional uses can ask for, and get, logical features without regard to who else has used or not used them in the past. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6468 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23033] New: gdb disassemble: ARM Thumb2 0x4503 is bad, not "cmp r3,r0"
https://sourceware.org/bugzilla/show_bug.cgi?id=23033 Bug ID: 23033 Summary: gdb disassemble: ARM Thumb2 0x4503 is bad, not "cmp r3,r0" Product: binutils Version: 2.31 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jreiser at BitWagon dot com Target Milestone: --- The ARM Thumb2 instruction word 0x4503 is disassembled as cmp r3,r0 by GNU gdb (GDB) 8.1.50.20180405-git built from source: commit 043e9508be0a4ea7ab56fd5716e4c06d609d13be (HEAD -> master, origin/master, origin/HEAD) Author: Nick Clifton Date: Thu Apr 5 14:44:05 2018 +0100 However the hardware documentation ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile ARM DDI 0487A.f (ID032515) Copyright 2013-2015 ARM Limited section F7.1.37 "CMP (register)" on page F7-2716 (.pdf page 2714) says that 0x4503 is UNPREDICTABLE because both bit 7 and bit 6 (the 0xc0 bits) are 0, while the instruction 0x45XX as CMP requires at least one "hi register" numbered >= 8. The Thumb1 instruction 0x4280|(Rm<<3)|Rn is CMP for two "lo registers" each numbered < 8. = test case "4503.S" .thumb_func _start: .globl _start .short 0x4503 cmp r3,r0 cmp r11,r0 = $ gcc -c 4503.S $ build-gdb/gdb/gdb --data-directory=build-gdb/gdb/data-directory 4503.o GNU gdb (GDB) 8.1.50.20180405-git (gdb) x/3i 1 0x1 <_start>:cmp r3, r0 <= should be "bad" 0x3 <_start+2>: cmp r3, r0 0x5 <_start+4>: cmp r11, r0 (gdb) x/3xh 0 0x0 <_start>: 0x4503 0x4283 0x4583 (gdb) q -- 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/11628] New: "ld -Ttext-segment=ORG" does not set PT_LOAD.p_vaddr
Sometimes ld uses the default builtin loader script to set the origin of the
text segment despite the commandline parameter -Ttext-segment=ORG. In
particular: binutils-2.20.1 on OpenSolaris (SunOS opensolaris 5.11 snv_111b
i86pc i386 i86pc Solaris) when configured and built to handle 64-bit binaries
via "./configure --enable-64-bit-bfd=yes". -Ttext-segment fails for 64-bit,
works for 32-bit.
Test case:
-start.s
_start: .globl _start
hlt
-
$ gcc -m32 -c -o start32.o start.s
$ gcc -m64 -c -o start64.o start.s
$ ld-2.20.1 -Ttext-segment=0x9000 -o start32 start32.o
$ readelf --segments start32 | grep LOAD
LOAD 0x00 0x9000 0x9000 0x00055 0x00055 R E 0x1000
## WORKS because p_vaddr is 0x9000, default is 0x08048000.
$ ld-2.20.1 --oformat elf64-x86-64 -m elf_x86_64 -Ttext-segment=0x567000 -o
start64 start64.o
$ readelf --segments start64 | grep LOAD
LOAD 0x 0x0040 0x0040
### FAILS because p_vaddr is the default 0x40, should be the specified
0x567000.
--
Summary: "ld -Ttext-segment=ORG" does not set PT_LOAD.p_vaddr
Product: binutils
Version: 2.20
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jreiser at BitWagon dot com
CC: bug-binutils at gnu dot org
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://sourceware.org/bugzilla/show_bug.cgi?id=11628
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11628] "ld -Ttext-segment=ORG" does not set PT_LOAD.p_vaddr
--- Additional Comments From jreiser at BitWagon dot com 2010-05-24 15:22 --- Arrggg. Must also specify "-z max-page-size=0x1000". There should be a warning about this (-Ttext-segment not a multiple of the max-page-size.) -- http://sourceware.org/bugzilla/show_bug.cgi?id=11628 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
