http://sourceware.org/bugzilla/show_bug.cgi?id=13400
Bug #: 13400
Summary: address capped at 1<<32
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: rol...@gnu.org
Classification: Unclassified
Created attachment 6049
--> http://sourceware.org/bugzilla/attachment.cgi?id=6049
assembly source
Something seems to cap explicitly-chosen addresses at 0x100000000 (1<<32).
Reproduce with the attached files:
$ as -o toobig.o toobig.s
$ ./ld/ld-new -m elf_x86_64 --build-id -static -z max-page-size=0x1000
--script=toobig.x -o toobig toobig.o
$ readelf -lSs toobig
There are 7 section headers, starting at offset 0x1c0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.build-i NOTE 0000000000010158 00000158
0000000000000024 0000000000000000 A 0 0 4
[ 2] .text PROGBITS 000000000001017c 0000017c
0000000000000001 0000000000000000 AX 0 0 4
[ 3] .reserve NOBITS 0000000000012000 00001000
00000000fffee000 0000000000000000 WA 0 0 1
[ 4] .shstrtab STRTAB 0000000000000000 0000017d
000000000000003d 0000000000000000 0 0 1
[ 5] .symtab SYMTAB 0000000000000000 00000380
00000000000000c0 0000000000000018 6 4 8
[ 6] .strtab STRTAB 0000000000000000 00000440
0000000000000028 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Elf file type is EXEC (Executable file)
Entry point 0x1017c
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000010000 0x0000000000010000
0x000000000000017d 0x000000000000017d R E 1000
LOAD 0x000000000000017d 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 1000
LOAD 0x0000000000001000 0x0000000000012000 0x0000000000012000
0x0000000000000000 0x00000000fffee000 1000
NOTE 0x0000000000000158 0x0000000000010158 0x0000000000010158
0x0000000000000024 0x0000000000000024 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 8
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .text
01
02 .reserve
03 .note.gnu.build-id
04
Symbol table '.symtab' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000010158 0 SECTION LOCAL DEFAULT 1
2: 000000000001017c 0 SECTION LOCAL DEFAULT 2
3: 0000000000012000 0 SECTION LOCAL DEFAULT 3
4: 0000001500000000 0 NOTYPE GLOBAL DEFAULT ABS RESERVE_TOP
5: 000000000001017d 0 NOTYPE GLOBAL DEFAULT ABS etext
6: 000000000001017c 0 NOTYPE GLOBAL DEFAULT 2 _start
7: 0000000000012000 0 NOTYPE GLOBAL DEFAULT ABS RESERVE_START
$
The RESERVE_TOP symbol has the correct value. But the section and segment
sizes derived from it are too way small. Suspiciously, they are such that
the top address is exactly 1<<32.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- 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
