- To: bugs at gnu dot org
- Subject: libc/1808: ld.so on powerpc-redhat-linux-gnu with ld -Ttext ...
- From: anton at mips dot complang dot tuwien dot ac dot at
- Date: Wed, 5 Jul 2000 19:38:55 +0200
>Number: 1808
>Category: libc
>Synopsis: ld.so segfaults when loading files linked with -Ttext 0x10000
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Jul 05 13:50:01 EDT 2000
>Last-Modified:
>Originator: Anton Ertl
>Organization:
TU Wien
>Release: libc-2.1
>Environment:
"Yellow Dog Linux 1.0"
Host type: powerpc-redhat-linux-gnu
System: Linux samhain.ifs.tuwien.ac.at 2.2.9 #5 Wed Jun 9 14:10:26 MEST 1999 ppc unknown
Architecture: ppc
Addons: crypt linuxthreads
Build CFLAGS: -O2 -g
Build CC: egcs
Compiler version: 2.95.2 19991024 (release/franzo)
Kernel headers: UTS_RELEASE
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
>Description:
When I link a program -Ttext 0x10000 (or any other value below
0x10000000, but not between 0x10000000 and 0x80000000), executing the
program produces a segfault before entering main. Gdb and
/proc/.../maps indicate that the segfault happens in code belonging to
ld.so.
Here are two postings I have written about the issue; I include them
just for completeness.
Newsgroups: comp.os.linux.powerpc
Subject: text segment in first 32MB
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
I need to get the text segment into the first 32MB (see below for the
motivation). In an earlier Linux-PPC version (don't know which) this
happened by default. On the version I use now (Yellow Dog Linux 1.0,
Linux-2.2.9, GNU ld 2.9.5, gcc-2.95.2) the text segment starts around
0x100002f0 by default, and if I try to change this with the ld option
-Ttext to something smaller, even a simple "hello, world" program
segfaults:
[anton@samhain tmp]$ ./a.out
Segmentation fault
[anton@samhain tmp]$ cat xxx.c
main()
{
puts("hello, world");
exit(0);
}
[anton@samhain tmp]$ gcc -O -Xlinker -Ttext -Xlinker 0x100000 xxx.c
[anton@samhain tmp]$ ./a.out
Segmentation fault
gdb reports that the SIGSEGV happens at "0x30003fd4 in ?? ()" (how did
it get there?), and apparently before entering main() (it does not
reach the breakpoint at main).
The same happens with -Ttext values of 0x08000000, 0x0f000000,
0x80000000, 0xf0000000, 0xfff00000 but not with 0x1f000000,
0x20000000, 0x70000000.
What is the reason for this behaviour? Is there a way to get the text
segment into the first 32MB? If yes, how do I do it?
Background:
The program for which I want this is Gforth
(http://www.complang.tuwien.ac.at/forth/gforth/), a Forth interpreter.
It can use either indirect or direct threading, with direct threading
being about 20% faster on the PPC 604e. For direct threading it uses
the ba (branch absolute) instruction to simulate some aspects of
indirect threading (branching to the run-time routines of colon
definitions, variables, etc.). The ba instruction can branch to
targets within the first or last 32MB of memory, so these routines
need to reside there; since these routines are in the text segment, I
want to have the text segment there.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Subject: Re: text segment in first 32MB
Newsgroups: comp.os.linux.powerpc
References: <8jsbe4$q4b$1@news.tuwien.ac.at>
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
In article <8jsbe4$q4b$1@news.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>How-To-Repeat:
Just paste this into your shell:
cat <<EOF >yyy.c
main()
{
puts("hello, world");
exit(0);
}
EOF
gcc -O -Xlinker -Ttext -Xlinker 0x10000 xxx.c
./a.out
>Fix:
>Audit-Trail:
>Unformatted:
>[anton@samhain tmp]$ cat xxx.c
>main()
>{
> puts("hello, world");
> exit(0);
>}
>
>[anton@samhain tmp]$ gcc -O -Xlinker -Ttext -Xlinker 0x100000 xxx.c
>[anton@samhain tmp]$ ./a.out
>Segmentation fault
>
>gdb reports that the SIGSEGV happens at "0x30003fd4 in ?? ()" (how did
>it get there?), and apparently before entering main() (it does not
>reach the breakpoint at main).
Ok, I found out a little more:
The 0x30003fd4 is in ld.so-2.1, and it apparently tries to access
something in the 0x0f0000 area (which is not mapped). Why does it try
to access there: Looking at the /proc/*/maps, I see the following
difference between the normal map and the one of the file created with
-Ttext:
with -Ttext 0x100000 (SIGSEGV):
address perms offset dev inode
00100000-00101000 r-xp 00010000 08:14 835638 /bigben/home/anton/tmp/a.out
00110000-00111000 rwxp 00010000 08:14 835638 /bigben/home/anton/tmp/a.out
10000000-10001000 r--p 00020000 08:14 835638 /bigben/home/anton/tmp/a.out
30000000-30014000 r-xp 00000000 08:03 28674 /lib/ld-2.1.so
30053000-30057000 rwxp 00013000 08:03 28674 /lib/ld-2.1.so
30057000-30058000 rwxp 00000000 00:00 0
7ffff000-80000000 rwxp 00000000 00:00 0
with -Ttext 0x20000000 (working):
10000000-10001000 r--p 00000000 08:14 835638 /bigben/home/anton/tmp/a.out
20000000-20001000 r-xp 00010000 08:14 835638 /bigben/home/anton/tmp/a.out
20010000-20011000 rwxp 00010000 08:14 835638 /bigben/home/anton/tmp/a.out
30000000-30014000 r-xp 00000000 08:03 28674 /lib/ld-2.1.so
30053000-30057000 rwxp 00013000 08:03 28674 /lib/ld-2.1.so
30057000-30058000 rwxp 00000000 00:00 0
7ffff000-80000000 rwxp 00000000 00:00 0
without -Ttext:
10000000-10001000 r-xp 00000000 08:14 835638 /bigben/home/anton/tmp/a.out
10010000-10011000 rwxp 00000000 08:14 835638 /bigben/home/anton/tmp/a.out
30000000-30014000 r-xp 00000000 08:03 28674 /lib/ld-2.1.so
30053000-30057000 rwxp 00013000 08:03 28674 /lib/ld-2.1.so
30057000-30058000 rwxp 00000000 00:00 0
7ffff000-80000000 rwxp 00000000 00:00 0
Note the difference in the offsets between the first segments (which
are apparently the text segments). The difference in offset
apparently comes from the section information in the binary (output of
objdump -h):
with -Ttext 0x100000:
Idx Name Size VMA LMA File off Algn
0 .text 000001e0 00100000 00100000 00010000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .interp 0000000d 10000114 10000114 00020114 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .note.ABI-tag 00000020 10000130 10000130 00020130 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .hash 00000034 10000150 10000150 00020150 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynsym 00000080 10000184 10000184 00020184 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .dynstr 0000007d 10000204 10000204 00020204 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version 00000010 10000282 10000282 00020282 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu.version_r 00000020 10000294 10000294 00020294 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rela.plt 0000003c 100002b4 100002b4 000202b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .init 00000028 001001e0 001001e0 000101e0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .fini 00000020 00100208 00100208 00010208 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .rodata 00000024 00100228 00100228 00010228 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .sdata2 00000000 0010024c 0010024c 0001024c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .data 00000020 00110250 00110250 00010250 2**2
CONTENTS, ALLOC, LOAD, DATA
14 .eh_frame 00000004 00110270 00110270 00010270 2**2
CONTENTS, ALLOC, LOAD, DATA
15 .dynamic 000000a0 00110274 00110274 00010274 2**2
CONTENTS, ALLOC, LOAD, DATA
16 .ctors 00000008 00110314 00110314 00010314 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .dtors 00000008 0011031c 0011031c 0001031c 2**2
CONTENTS, ALLOC, LOAD, DATA
18 .got 00000010 00110324 00110324 00010324 2**2
CONTENTS, ALLOC, LOAD, DATA
19 .sdata 00000000 00110334 00110334 00010334 2**2
CONTENTS, ALLOC, LOAD, DATA
20 .sbss 00000000 00110334 00110334 00010334 2**0
ALLOC
21 .plt 00000084 00110334 00110334 00010334 2**2
ALLOC, CODE
22 .bss 00000030 001103c0 001103c0 0001033c 2**2
ALLOC
23 .stab 00000744 00000000 00000000 000202f0 2**2
CONTENTS, READONLY, DEBUGGING
24 .stabstr 00001342 00000000 00000000 00020a34 2**0
CONTENTS, READONLY, DEBUGGING
25 .comment 0000013e 001103f0 001103f0 00021d76 2**0
CONTENTS, READONLY
with -Ttext 0x20000000 (working):
Idx Name Size VMA LMA File off Algn
0 .text 000001e0 20000000 20000000 00010000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .interp 0000000d 10000114 10000114 00000114 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .note.ABI-tag 00000020 10000130 10000130 00000130 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .hash 00000034 10000150 10000150 00000150 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynsym 00000080 10000184 10000184 00000184 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .dynstr 0000007d 10000204 10000204 00000204 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version 00000010 10000282 10000282 00000282 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu.version_r 00000020 10000294 10000294 00000294 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rela.plt 0000003c 100002b4 100002b4 000002b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .init 00000028 200001e0 200001e0 000101e0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .fini 00000020 20000208 20000208 00010208 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .rodata 00000024 20000228 20000228 00010228 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .sdata2 00000000 2000024c 2000024c 0001024c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .data 00000020 20010250 20010250 00010250 2**2
CONTENTS, ALLOC, LOAD, DATA
14 .eh_frame 00000004 20010270 20010270 00010270 2**2
CONTENTS, ALLOC, LOAD, DATA
15 .dynamic 000000a0 20010274 20010274 00010274 2**2
CONTENTS, ALLOC, LOAD, DATA
16 .ctors 00000008 20010314 20010314 00010314 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .dtors 00000008 2001031c 2001031c 0001031c 2**2
CONTENTS, ALLOC, LOAD, DATA
18 .got 00000010 20010324 20010324 00010324 2**2
CONTENTS, ALLOC, LOAD, DATA
19 .sdata 00000000 20010334 20010334 00010334 2**2
CONTENTS, ALLOC, LOAD, DATA
20 .sbss 00000000 20010334 20010334 00010334 2**0
ALLOC
21 .plt 00000084 20010334 20010334 00010334 2**2
ALLOC, CODE
22 .bss 00000030 200103c0 200103c0 0001033c 2**2
ALLOC
23 .stab 00000744 00000000 00000000 0001033c 2**2
CONTENTS, READONLY, DEBUGGING
24 .stabstr 00001342 00000000 00000000 00010a80 2**0
CONTENTS, READONLY, DEBUGGING
25 .comment 0000013e 200103f0 200103f0 00011dc2 2**0
CONTENTS, READONLY
without -Ttext:
0 .interp 0000000d 10000114 10000114 00000114 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 00000020 10000130 10000130 00000130 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .hash 00000034 10000150 10000150 00000150 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynsym 00000080 10000184 10000184 00000184 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynstr 0000007d 10000204 10000204 00000204 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .gnu.version 00000010 10000282 10000282 00000282 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version_r 00000020 10000294 10000294 00000294 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rela.plt 0000003c 100002b4 100002b4 000002b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .text 000001e0 100002f0 100002f0 000002f0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .init 00000028 100004d0 100004d0 000004d0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .fini 00000020 100004f8 100004f8 000004f8 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .rodata 00000024 10000518 10000518 00000518 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .sdata2 00000000 1000053c 1000053c 0000053c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .data 00000020 10010540 10010540 00000540 2**2
CONTENTS, ALLOC, LOAD, DATA
14 .eh_frame 00000004 10010560 10010560 00000560 2**2
CONTENTS, ALLOC, LOAD, DATA
15 .dynamic 000000a0 10010564 10010564 00000564 2**2
CONTENTS, ALLOC, LOAD, DATA
16 .ctors 00000008 10010604 10010604 00000604 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .dtors 00000008 1001060c 1001060c 0000060c 2**2
CONTENTS, ALLOC, LOAD, DATA
18 .got 00000010 10010614 10010614 00000614 2**2
CONTENTS, ALLOC, LOAD, DATA
19 .sdata 00000000 10010624 10010624 00000624 2**2
CONTENTS, ALLOC, LOAD, DATA
20 .sbss 00000000 10010624 10010624 00000624 2**0
ALLOC
21 .plt 00000084 10010624 10010624 00000624 2**2
ALLOC, CODE
22 .bss 00000030 100106b0 100106b0 0000062c 2**2
ALLOC
23 .stab 00000744 00000000 00000000 0000062c 2**2
CONTENTS, READONLY, DEBUGGING
24 .stabstr 00001342 00000000 00000000 00000d70 2**0
CONTENTS, READONLY, DEBUGGING
25 .comment 0000013e 100106e0 100106e0 000020b2 2**0
CONTENTS, READONLY
Maybe ld.so interprets something wrong if the offsets are as generated
by -Ttext 0x100000.
I played around a little with also using -Tdata, and with calling the
linker directly, and reordering the options. No joy.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html