|
From: John C. <joh...@ta...> - 2003-12-22 00:56:21
|
I'm trying the latest (from about midnight UTC) version of Valgrind
from CVS on executable's created for eCos synthetic target.
(eCos is a RTOS that has been ported to many platforms, including
i386, running on Linux. There is a "Synthetic Hal" Hardware Abstraction Layer
that just pop's out of eCos and invokes Linux system services.)
I suspect it is because of the, umm, unusual linker script we are
using, but valgrind produces the following error message from ume.c
from the routine...
static int load_ELF(char *hdr, int len, int fd, const char *name,
struct exeinfo *info)
==========================
Executable is mapped outside of range 0x80d3000-0xbffff000
failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
==========================
Here is what is probably the relevant portion of the linker script...
MEMORY
{
rom : ORIGIN = 0x1000000, LENGTH = 0x800000
ram : ORIGIN = 0x2000000, LENGTH = 0x800000
}
Question 1)
Is this a valgrind bug? (I expect not)
Question 2)
Is there a way I could tweak valgrind to cope with this?
Question 3)
What is valgrind expecting at this point? ie. Could I tweak our linker
script to create an executable valgrind would cope with?
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : joh...@ta...
New Zealand
A Million Monkeys can inflict worse things than just Shakespeare on
your system.
|
|
From: Sefer T. <se...@ho...> - 2003-12-23 21:07:59
|
Hi,
I'm experiencing that problem as well when using the HEAD branch of the cvs.
bash$ /opt/valgrind/bin/valgrind /bin/ls
Executable is mapped outside of range 0x80cf000-0xbffff000
failed to load /opt/valgrind/lib/valgrind/stage2: Cannot allocate memory
I have Mandrake 9.2 (with all the cooker additions) running on kernel
2.4.23, glibc 2.3.3, binutils 2.14.19.0.7, gcc 3.3.2
Basically it's a fairly standard system, containing up to date versions of
most development tools.
Here's some information on the files based on the ideas suggested in the
previous conversations on the issue.
Does that give any additional clues? Anything else I can provide?
bash$ readelf -hlS /opt/valgrind/bin/valgrind
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x804941c
Start of program headers: 52 (bytes into file)
Start of section headers: 533632 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 4
Size of section headers: 40 (bytes)
Number of section headers: 30
Section header string table index: 27
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk
Inf Al [ 0] NULL 00000000 000000 000000 00
0 0 0 [ 1] .init PROGBITS 080480d4 0000d4 000017 00
AX 0 0 4 [ 2] .text PROGBITS 08048100 000100
04c321 00 AX 0 0 32 [ 3] __libc_freeres_fn PROGBITS 08094430
04c430 0004c1 00 AX 0 0 16 [ 4] .fini PROGBITS
080948f4 04c8f4 00001a 00 AX 0 0 4 [ 5] .rodata PROGBITS
08094920 04c920 013793 00 A 0 0 32 [ 6] __libc_subfreeres PROGBITS
080a80b4 0600b4 00002c 00 A 0 0 4 [ 7] __libc_atexit
PROGBITS 080a80e0 0600e0 000004 00 A 0 0 4 [ 8] .eh_frame
PROGBITS 080a80e4 0600e4 00186c 00 A 0 0 4 [ 9] .data
PROGBITS 080aa960 061960 000f28 00 WA 0 0 32 [10] .ctors
PROGBITS 080ab888 062888 000008 00 WA 0 0 4 [11]
.dtors PROGBITS 080ab890 062890 000008 00 WA 0 0 4
[12] .jcr PROGBITS 080ab898 062898 000004 00 WA 0 0
4 [13] .got PROGBITS 080ab89c 06289c 000010 04 WA 0
0 4 [14] .bss NOBITS 080ab8c0 0628c0 023500 00 WA
0 0 32 [15] __libc_freeres_pt NOBITS 080cedc0 0628c0 000018 00
WA 0 0 4 [16] .comment PROGBITS 00000000 0628c0 0001fb
00 0 0 1 [17] .debug_aranges PROGBITS 00000000 062ac0
000118 00 0 0 8 [18] .debug_pubnames PROGBITS 00000000
062bd8 000228 00 0 0 1 [19] .debug_info PROGBITS
00000000 062e00 01503f 00 0 0 1 [20] .debug_abbrev PROGBITS
00000000 077e3f 001046 00 0 0 1 [21] .debug_line PROGBITS
00000000 078e85 000f8c 00 0 0 1 [22] .debug_frame
PROGBITS 00000000 079e14 00050c 00 0 0 4 [23] .debug_str
PROGBITS 00000000 07a320 006f57 01 MS 0 0 1 [24] .debug_loc
PROGBITS 00000000 081277 001072 00 0 0 1 [25]
.note.ABI-tag NOTE 080480b4 0000b4 000020 00 A 0 0 4
[26] .debug_ranges PROGBITS 00000000 0822e9 000060 00 0 0
1 [27] .shstrtab STRTAB 00000000 082349 000135 00 0
0 1 [28] .symtab SYMTAB 00000000 082930 005e50 10
29 1ff 4 [29] .strtab STRTAB 00000000 088780 005051 00
0 0 1Key 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)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x08048000 0x08048000 0x61950 0x61950 R E 0x1000
LOAD 0x061960 0x080aa960 0x080aa960 0x00f4c 0x24478 RW 0x1000
NOTE 0x0000b4 0x080480b4 0x080480b4 0x00020 0x00020 R 0x4
STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping:
Segment Sections...
00 .init .text __libc_freeres_fn .fini .rodata __libc_subfreeres
__libc_atexit .eh_frame .note.ABI-tag
01 .data .ctors .dtors .jcr .got .bss __libc_freeres_ptrs
02 .note.ABI-tag
03
bash$ ldd /opt/valgrind/lib/valgrind/stage2
libdl.so.2 => /lib/libdl.so.2 (0x4002e000)
libc.so.6 => /lib/i686/libc.so.6 (0x40031000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
bash$ readelf -hlS /opt/valgrind/lib/valgrind/stage2
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x8055548
Start of program headers: 52 (bytes into file)
Start of section headers: 1810508 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 37
Section header string table index: 34
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk
Inf Al [ 0] NULL 00000000 000000 000000 00
0 0 0 [ 1] .interp PROGBITS 08048134 000134 000013 00
A 0 0 1 [ 2] .note.ABI-tag NOTE 08048148 000148
000020 00 A 0 0 4 [ 3] .hash HASH 08048168
000168 0016a4 04 A 4 0 4 [ 4] .dynsym DYNSYM
0804980c 00180c 0039e0 10 A 5 1 4 [ 5] .dynstr STRTAB
0804d1ec 0051ec 005489 00 A 0 0 1 [ 6] .gnu.version VERSYM
08052676 00a676 00073c 02 A 4 0 2 [ 7] .gnu.version_r
VERNEED 08052db4 00adb4 000080 00 A 5 2 4 [ 8] .rel.dyn
REL 08052e34 00ae34 000018 08 A 4 0 4 [ 9] .rel.plt
REL 08052e4c 00ae4c 000168 08 A 4 b 4 [10] .init
PROGBITS 08052fb4 00afb4 000017 00 AX 0 0 4 [11]
.plt PROGBITS 08052fcc 00afcc 0002e0 04 AX 0 0 4
[12] .text PROGBITS 080532b0 00b2b0 058244 00 AX 0 0
16 [13] .fini PROGBITS 080ab4f4 0634f4 00001a 00 AX 0
0 4 [14] .rodata PROGBITS 080ab520 063520 01bde0 00 A
0 0 32 [15] .eh_frame_hdr PROGBITS 080c7300 07f300 000024 00
A 0 0 4 [16] .eh_frame PROGBITS 080c7324 07f324
00008c 00 A 0 0 4 [17] .data PROGBITS 080c8000
080000 000494 00 WA 0 0 32 [18] .dynamic DYNAMIC
080c8494 080494 0000d0 08 WA 5 0 4 [19] .ctors PROGBITS
080c8564 080564 000008 00 WA 0 0 4 [20] .dtors PROGBITS
080c856c 08056c 000008 00 WA 0 0 4 [21] .jcr
PROGBITS 080c8574 080574 000004 00 WA 0 0 4 [22] .got
PROGBITS 080c8578 080578 0000c4 04 WA 0 0 4 [23] .bss
NOBITS 080c8640 080640 0579a0 00 WA 0 0 32 [24]
.comment PROGBITS 00000000 080640 00088e 00 0 0 1
[25] .debug_aranges PROGBITS 00000000 080ed0 000518 00 0 0
8 [26] .debug_pubnames PROGBITS 00000000 0813e8 007a49 00 0
0 1 [27] .debug_info PROGBITS 00000000 088e31 0a6ddf 00
0 0 1 [28] .debug_abbrev PROGBITS 00000000 12fc10 009551 00
0 0 1 [29] .debug_line PROGBITS 00000000 139161 00ddcc
00 0 0 1 [30] .debug_frame PROGBITS 00000000 146f30
01610c 00 0 0 4 [31] .debug_str PROGBITS 00000000
15d03c 018236 01 MS 0 0 1 [32] .debug_loc PROGBITS
00000000 175272 04496d 00 0 0 1 [33] .debug_ranges PROGBITS
00000000 1b9bdf 000318 00 0 0 1 [34] .shstrtab STRTAB
00000000 1b9ef7 000152 00 0 0 1 [35] .symtab
SYMTAB 00000000 1ba614 009150 10 36 501 4 [36] .strtab
STRTAB 00000000 1c3764 00afe0 00 0 0 1Key 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)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x08048134 0x08048134 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x7f3b0 0x7f3b0 R E 0x1000
LOAD 0x080000 0x080c8000 0x080c8000 0x0063c 0x57fe0 RW 0x1000
DYNAMIC 0x080494 0x080c8494 0x080c8494 0x000d0 0x000d0 RW 0x4
NOTE 0x000148 0x08048148 0x08048148 0x00020 0x00020 R 0x4
GNU_EH_FRAME 0x07f300 0x080c7300 0x080c7300 0x00024 0x00024 R 0x4
STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version
.gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata
.eh_frame_hdr .eh_frame
03 .data .dynamic .ctors .dtors .jcr .got .bss
04 .dynamic
05 .note.ABI-tag
06 .eh_frame_hdr
07
Thanks,
Sefer.
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus
|
|
From: Jeremy F. <je...@go...> - 2003-12-24 08:25:34
|
On Tue, 2003-12-23 at 13:07, Sefer Tov wrote: > Hi, > > I'm experiencing that problem as well when using the HEAD branch of the cvs. > > bash$ /opt/valgrind/bin/valgrind /bin/ls > Executable is mapped outside of range 0x80cf000-0xbffff000 > failed to load /opt/valgrind/lib/valgrind/stage2: Cannot allocate memory I just checked in a fix for this; could you update and try again? Otherwise, could you send me your generated stage2.lds? J |
|
From: Dirk M. <dm...@gm...> - 2003-12-22 01:04:17
|
On Monday 22 December 2003 01:56, John Carter wrote: > Question 1) > Is this a valgrind bug? (I expect not) yes and no. There was lately a huge commit by Jeremy, which wasn't discussed as far as I can see. It maps valgrind into the high address space of the process, to be as far as possible separated (and to be able to use the x86 segment limit to protect it from being trashed by the misbehaving client process accidentally). Unfortunately, this has a number of very serious disadvantages, and you're describing one of it. I've hit probably almost all others meanwhile. For now, I would recommend you to update to VALGRIND_2_0_REALLY branch instead. Dirk |
|
From: Julian S. <js...@ac...> - 2003-12-22 01:14:33
|
Dirk, > client process accidentally). Unfortunately, this has a number of very > serious disadvantages, and you're describing one of it. I've hit probably > almost all others meanwhile. There's certainly some breakage caused by this commit. Could you list the the problems it gave you, since I would like to understand the consequences of this commit in more detail. Thanks, J |
|
From: Julian S. <js...@ac...> - 2003-12-22 01:05:41
|
I'd guess your image asks to be mapped at some place V doesn't
expect, and V can't do it.
> MEMORY
> {
> rom : ORIGIN = 0x1000000, LENGTH = 0x800000
> ram : ORIGIN = 0x2000000, LENGTH = 0x800000
> }
Does this work?
MEMORY
{
rom : ORIGIN = 0x4000000, LENGTH = 0x800000
ram : ORIGIN = 0x5000000, LENGTH = 0x800000
}
J
|
|
From: Dirk M. <dm...@gm...> - 2003-12-22 01:20:59
|
On Monday 22 December 2003 03:30, Julian Seward wrote: > There's certainly some breakage caused by this commit. Could you list the > the problems it gave you, since I would like to understand the consequences > of this commit in more detail. Well, one of the problems is that when you (or your administrator) set up an ulimit on the client address space, then valgrind will not start, since it cannot remap itself. Since I always use ulimits for debugging setups (to avoid that a quickly recursing or memory eating process kills my machine), thats a bit annoying. I have a couple of other problems, which I can't pinpoint yet where they come from (don't have much time right now for investigating). Dirk |
|
From: Jeremy F. <je...@go...> - 2003-12-22 06:51:49
|
On Sun, 2003-12-21 at 17:20, Dirk Mueller wrote: > Well, one of the problems is that when you (or your administrator) set up an > ulimit on the client address space, then valgrind will not start, since it > cannot remap itself. It's actually that stage1 tries to grow it's bss up to where stage2 wants it, so that stage2 can use brk(). But this really isn't necessary, and I've been thinking about changing it won't work without a datasize ulimit. I'd be interested to know what other bugs you've hit. J |
|
From: Jeremy F. <je...@go...> - 2003-12-22 06:49:24
|
On Sun, 2003-12-21 at 16:56, John Carter wrote: > Question 1) > Is this a valgrind bug? (I expect not) Actually, I think it is. I'm not sure why it isn't allowing executables to be mapped below 0x80d3000 - it should be fine. (If you were trying to load something high, like >0x80000000, then it would be more of an issue). J |
|
From: Jeremy F. <je...@go...> - 2003-12-22 08:56:09
|
On Sun, 2003-12-21 at 16:56, John Carter wrote: > I'm trying the latest (from about midnight UTC) version of Valgrind > from CVS on executable's created for eCos synthetic target. > > (eCos is a RTOS that has been ported to many platforms, including > i386, running on Linux. There is a "Synthetic Hal" Hardware Abstraction Layer > that just pop's out of eCos and invokes Linux system services.) > > I suspect it is because of the, umm, unusual linker script we are > using, but valgrind produces the following error message from ume.c > from the routine... > > static int load_ELF(char *hdr, int len, int fd, const char *name, > struct exeinfo *info) > > ========================== > Executable is mapped outside of range 0x80d3000-0xbffff000 > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory > ========================== Can you send me the the output of "readelf -hlS yourprog"? I can't reproduce this just by playing with the load address. Could you also send me your whole linker script? J |
|
From: John C. <joh...@ta...> - 2003-12-23 00:43:04
|
Ok...
1) The reason why I'm using the bleeding edge Valgrind is I want to
use the new Full Virtualization stuff that allows non-statically
linked executables to be valgrinded. In particular ecos synthetic target
executables.
2) I have just tried Julian's suggested tweak to the linker script, it
required one or two more tweaks to get it to link. It now links
and run's outside of valgrind but under valgrind it says...
valgrind -v --leak-check=3Dyes ./MYPROG --io --nr --nw --exit
Executable is mapped outside of range 0x80d3000-0xbffff000
failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
3) You say it may be a bug in valgrind, so I followed in gdb to the if
statement in ume.c (line 472) that decides to print the error message.
if (info->exe_base !=3D info->exe_end) {
if (minaddr >=3D maxaddr ||
=09 (minaddr < info->exe_base ||
=09 maxaddr > info->exe_end)) {
=09 fprintf(stderr, "Executable is mapped outside of range %p-%p\n",
=09=09 (void *)info->exe_base, (void *)info->exe_end);
=09 return ENOMEM;
}
}
(gdb) p/x *info
p/x *info
$6 =3D {
setbrk =3D 0x1,
map_base =3D 0xb0000000,
exe_base =3D 0x80d3000,
exe_end =3D 0xbffff000,
phdr =3D 0x8048034,
phnum =3D 0x8,
interp_base =3D 0x0,
entry =3D 0x80558f0,
init_eip =3D 0x0,
brkbase =3D 0x0,
argv0 =3D 0x0,
argv1 =3D 0x0,
argv =3D 0x0
}
(gdb) p/x minaddr
$7 =3D 0x8048000
(gdb) p/x maxaddr
$8 =3D 0x8131900
> Can you send me the the output of "readelf -hlS yourprog"? I can't
> reproduce this just by playing with the load address. Could you also
> send me your whole linker script?
4) Here it is...
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x4000000
Start of program headers: 52 (bytes into file)
Start of section headers: 3122312 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 40 (bytes)
Number of section headers: 17
Section header string table index: 14
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk I=
nf Al
[ 0] NULL 00000000 000000 000000 00 0 =
0 0
[ 1] .vectors PROGBITS 04000000 085fa0 000000 00 W 0 =
0 1
[ 2] .text PROGBITS 04000000 001000 06bbd1 00 AX 0 =
0 4
[ 3] .fini PROGBITS 0406bbd4 085fa0 000000 00 W 0 =
0 1
[ 4] .rodata1 PROGBITS 0406bbd8 085fa0 000000 00 W 0 =
0 1
[ 5] .rodata PROGBITS 0406bbd8 06cbd8 01759d 00 A 0 =
0 32
[ 6] .fixup PROGBITS 04083178 085fa0 000000 00 W 0 =
0 1
[ 7] .eh_frame PROGBITS 04083178 084178 000128 00 WA 0 =
0 4
[ 8] .gcc_except_table PROGBITS 040832a0 085fa0 000000 00 W 0 =
0 1
[ 9] .data PROGBITS 05000000 085000 000fa0 00 WA 0 =
0 32
[10] .sbss PROGBITS 05000fa0 085fa0 000000 00 W 0 =
0 1
[11] .bss NOBITS 05000fa0 085fa0 08fcb8 00 WA 0 =
0 32
[12] .stab PROGBITS 00000000 085fa0 109e18 0c 13 =
0 4
[13] .stabstr STRTAB 00000000 18fdb8 16a64b 00 0 =
0 1
[14] .shstrtab STRTAB 00000000 2fa403 000084 00 0 =
0 1
[15] .symtab SYMTAB 00000000 2fa730 0160d0 10 16 9=
dd 4
[16] .strtab STRTAB 00000000 310800 0293d3 00 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)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x04000000 0x04000000 0x832a0 0x832a0 RWE 0x1000
LOAD 0x085000 0x05000000 0x05000000 0x00fa0 0x90c58 RW 0x1000
Section to Segment mapping:
Segment Sections...
00 .text .rodata .eh_frame
01 .data .bss
4) The linker script is basically just the eCos V2 synthetic target
script with Julian tweaks.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
STARTUP(vectors.o)
ENTRY(_start)
INPUT(extras.o)
GROUP(libtarget.a libgcc.a libsupc++.a)
MEMORY
{
rom : ORIGIN =3D 0x4000000, LENGTH =3D 0x800000
ram : ORIGIN =3D 0x5000000, LENGTH =3D 0x800000
}
SECTIONS
{
.vectors 0x4000000 : { . =3D .; KEEP(*(.vectors)) } > rom
.text ALIGN (0x4) : { _stext =3D .; *(.text*) *(.gnu.warning) *(.gnu.li=
nkonce.t.*) *(.init) } > rom _etext =3D .; PROVIDE (etext =3D .);
.fini ALIGN (0x4) : { . =3D .; *(.fini) } > rom
.rodata1 ALIGN (0x8) : { . =3D .; *(.rodata1) } > rom
.rodata ALIGN (0x8) : { . =3D .; *(.rodata*) *(.gnu.linkonce.r.*) } > r=
om
.fixup ALIGN (0x4) : { _FIXUP_START_ =3D ABSOLUTE(.); *(.fixup) _FIXUP_=
END_ =3D ABSOLUTE(.);} > rom
.rel.text : { *(.rel.text) *(.rel.text.*) *(.rel.gnu.linkonce.t*) } > r=
om .rela.text : { *(.rela.text) *(.rela.text.*) *(.rela.gnu.linkonce.t*) } =
> rom .rel.data : { *(.rel.data) *(.rel.data.*) *(.rel.gnu.linkonce.d*) } >=
rom .rela.data : { *(.rela.data) *(.rela.data.*) *(.rela.gnu.linkonce.d*) =
} > rom .rel.rodata : { *(.rel.rodata) *(.rel.rodata.*) *(.rel.gnu.linkonce=
=2Er*) } > rom .rela.rodata : { *(.rela.rodata) *(.rela.rodata.*) *(.rela.g=
nu.linkonce.r*) } > rom .rel.got : { *(.rel.got) } > rom .rela.got : { *(.r=
ela.got) } > rom .rel.ctors : { *(.rel.ctors) } > rom .rela.ctors : { *(.re=
la.ctors) } > rom .rel.dtors : { *(.rel.dtors) } > rom .rela.dtors : { *(.r=
ela.dtors) } > rom .rel.init : { *(.rel.init) } > rom .rela.init : { *(.rel=
a.init) } > rom .rel.fini : { *(.rel.fini) } > rom .rela.fini : { *(.rela.f=
ini) } > rom .rel.bss : { *(.rel.bss) } > rom .rela.bss : { *(.rela.bss) } =
> rom .rel.plt : { *(.rel.plt) } > rom .rela.plt : { *(.rela.plt) } > rom .=
rel.dyn : { *(.rel.dyn) } > rom
.eh_frame ALIGN (0x4) : { . =3D .; __EH_FRAME_BEGIN__ =3D .; KEEP(*(.eh=
_frame)) __FRAME_END__ =3D .; . =3D . + 8; } > rom =3D 0
.rel.got ALIGN (0x1) : { *(.rel.got) } > rom
.gcc_except_table ALIGN (0x1) : { _EXCEPT_START_ =3D ABSOLUTE(.); *(.gc=
c_except_table) _EXCEPT_END_ =3D ABSOLUTE(.);} > rom
.data 0x5000000 : { __ram_data_start =3D ABSOLUTE(.); *(.data*) *(.gnu.=
linkonce.d.*) _GOT1_START_ =3D ABSOLUTE(.); *(.got1) _GOT1_END_ =3D ABSOLUT=
E(.); . =3D ALIGN(8); __CTOR_LIST__ =3D ABSOLUTE(.); KEEP(*(SORT(.ctors*)))=
__CTOR_END__ =3D ABSOLUTE(.); __DTOR_LIST__ =3D ABSOLUTE(.); KEEP(*(SORT(.=
dtors*))) __DTOR_END__ =3D ABSOLUTE(.); . =3D ALIGN(32); KEEP(*( SORT (.eco=
s.table.*))); _GOT2_START_ =3D ABSOLUTE(.); *(.got2) _GOT2_END_ =3D ABSOLUT=
E(.); _GOT_START_ =3D ABSOLUTE(.); _GLOBAL_OFFSET_TABLE_ =3D ABSOLUTE(. + 3=
2768); _SDA_BASE_ =3D ABSOLUTE(.); *(.got.plt) *(.got) _GOT_END_ =3D ABSOLU=
TE(.); *(.dynamic) _SDATA_START_ =3D ABSOLUTE(.); *(.sdata*) *(.gnu.linkonc=
e.s.*) } > ram __rom_data_start =3D LOADADDR(.data); __ram_data_end =3D .; =
PROVIDE(__ram_data_end =3D .); _edata =3D .; PROVIDE (edata =3D .);
.sbss ALIGN (0x4) : { __bss_start =3D ABSOLUTE (.); _SBSS_START_ =3D AB=
SOLUTE(.); *(.sbss*) *(.gnu.linkonce.sb.*) _SBSS_END_ =3D ABSOLUTE(.); *(.s=
common*) } > ram
.bss ALIGN (0x10) : { . =3D .; *(.dynbss*) *(.bss*) *(COMMON) *(.gnu.li=
nkonce.b.*) } > ram __bss_end =3D .;
__heap1 =3D ALIGN (0x10);
. =3D ALIGN(4); _end =3D .; PROVIDE (end =3D .);
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Mon, 22 Dec 2003, Jeremy Fitzhardinge wrote:
> On Sun, 2003-12-21 at 16:56, John Carter wrote:
> > I'm trying the latest (from about midnight UTC) version of Valgrind
> > from CVS on executable's created for eCos synthetic target.
> >
> > (eCos is a RTOS that has been ported to many platforms, including
> > i386, running on Linux. There is a "Synthetic Hal" Hardware Abstraction=
Layer
> > that just pop's out of eCos and invokes Linux system services.)
> >
> > I suspect it is because of the, umm, unusual linker script we are
> > using, but valgrind produces the following error message from ume.c
> > from the routine...
> >
> > static int load_ELF(char *hdr, int len, int fd, const char *name,
> > struct exeinfo *info)
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
> > Executable is mapped outside of range 0x80d3000-0xbffff000
> > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>
> Can you send me the the output of "readelf -hlS yourprog"? I can't
> reproduce this just by playing with the load address. Could you also
> send me your whole linker script?
>
> =09J
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : joh...@ta...
New Zealand
A Million Monkeys can inflict worse things than just Shakespeare on
your system.
|
|
From: Jeremy F. <je...@go...> - 2003-12-23 01:05:44
|
On Mon, 2003-12-22 at 16:42, John Carter wrote: > Ok... > > 1) The reason why I'm using the bleeding edge Valgrind is I want to > use the new Full Virtualization stuff that allows non-statically > linked executables to be valgrinded. In particular ecos synthetic target > executables. Yup, makes sense. I was thinking that static support would be useful for this kind of thing. > 2) I have just tried Julian's suggested tweak to the linker script, it > required one or two more tweaks to get it to link. It now links > and run's outside of valgrind but under valgrind it says... > > valgrind -v --leak-check=yes ./MYPROG --io --nr --nw --exit > Executable is mapped outside of range 0x80d3000-0xbffff000 > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory Ah, I think this we've chasing a red herring. The problem isn't your executable; it's the linker you used to build Valgrind. What does readelf -hls /usr/local/lib/valgrind/stage2 say? I'm guessing the Makefile in coregrind/x86 has used the wrong version of "ld" to make coregrind/x86/stage2.lds. J |
|
From: Jeremy F. <je...@go...> - 2003-12-23 01:16:13
|
On Mon, 2003-12-22 at 17:05, Jeremy Fitzhardinge wrote: > Ah, I think this we've chasing a red herring. The problem isn't your > executable; it's the linker you used to build Valgrind. What does > readelf -hls /usr/local/lib/valgrind/stage2 say? I'm guessing the > Makefile in coregrind/x86 has used the wrong version of "ld" to make > coregrind/x86/stage2.lds. I just checked in a fix to use gcc's ld rather than some ld it found in the path. Make sure you regenerate the Makefiles. and tell me if this helps J |
|
From: John C. <joh...@ta...> - 2003-12-23 01:47:12
Attachments:
tlog.bz2
|
Hmm. Linker, hmm, we're using the version of the GNU tool chain provided with ecos to build the apps. I forget the reason why, possibly because the standard gcc toolchain links to the a sharable version of libgcc.so (This is aimed at embedded apps that live in a device without so much as a loaded that can read elf executables let alone a dynamic linker.) I have attached a bzip2 version of the readelf -hls /usr/local/lib/valgrind/stage2 output. It is rather large. I'll try tomorrow, to use the standard linux toolchain and see what happens. On Mon, 22 Dec 2003, Jeremy Fitzhardinge wrote: > On Mon, 2003-12-22 at 16:42, John Carter wrote: > > Ok... > > > > 1) The reason why I'm using the bleeding edge Valgrind is I want to > > use the new Full Virtualization stuff that allows non-statically > > linked executables to be valgrinded. In particular ecos synthetic target > > executables. > > Yup, makes sense. I was thinking that static support would be useful > for this kind of thing. > > > 2) I have just tried Julian's suggested tweak to the linker script, it > > required one or two more tweaks to get it to link. It now links > > and run's outside of valgrind but under valgrind it says... > > > > valgrind -v --leak-check=yes ./MYPROG --io --nr --nw --exit > > Executable is mapped outside of range 0x80d3000-0xbffff000 > > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory > > Ah, I think this we've chasing a red herring. The problem isn't your > executable; it's the linker you used to build Valgrind. What does > readelf -hls /usr/local/lib/valgrind/stage2 say? I'm guessing the > Makefile in coregrind/x86 has used the wrong version of "ld" to make > coregrind/x86/stage2.lds. > > J > John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : joh...@ta... New Zealand A Million Monkeys can inflict worse things than just Shakespeare on your system. |
|
From: John C. <joh...@ta...> - 2003-12-23 01:51:00
|
On Mon, 22 Dec 2003, Jeremy Fitzhardinge wrote: > I just checked in a fix to use gcc's ld rather than some ld it found in > the path. Make sure you regenerate the Makefiles. and tell me if this > helps I just pull a fresh version out and said "make" and then "make install" and tried that, no difference. I suspect it is probably the weird version of gcc/ld that I'm using to build my app rather than how valgrind is being built. I will try use the same gcc/ld to build my app as valgrind tomorrow. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : joh...@ta... New Zealand A Million Monkeys can inflict worse things than just Shakespeare on your system. |
|
From: Jeremy F. <je...@go...> - 2003-12-23 02:03:41
|
On Mon, 2003-12-22 at 17:50, John Carter wrote: > I just pull a fresh version out and said "make" and then "make > install" and tried that, no difference. You need to do a "sh autogen.sh; ./configure" to regenerate all the Makefiles from their .am counterparts. > I suspect it is probably the weird version of gcc/ld that I'm using to > build my app rather than how valgrind is being built. > > I will try use the same gcc/ld to build my app as valgrind tomorrow. No, that stage2 readelf output is completely broken. I'm pretty sure the bug is in Valgrind's Makefiles. Valgrind shouldn't care about *how* your binary was generated, so long as it is within the valid client address range (which it is). Actually, could you send me the output of your "ld --verbose" and "coregrind/x86/stage2.lds"? J |
|
From: Jeremy F. <je...@go...> - 2003-12-23 02:06:47
|
On Mon, 2003-12-22 at 17:50, John Carter wrote:
> On Mon, 22 Dec 2003, Jeremy Fitzhardinge wrote:
>
> > I just checked in a fix to use gcc's ld rather than some ld it found in
> > the path. Make sure you regenerate the Makefiles. and tell me if this
> > helps
>
> I just pull a fresh version out and said "make" and then "make
> install" and tried that, no difference.
Oh, and it looks like the change hasn't made it to anonCVS yet. I guess
it will turn up soon, though you can see from the checkin message the
change is trivial:
--- valgrind/coregrind/x86/Makefile.am #1.2:1.3
@@ -14,5 +14,5 @@
# Extract ld's default linker script and hack it to our needs
stage2.lds: Makefile
- ld --verbose | sed \
+ $(CC) -Wl,--verbose -nostdlib 2>&1 | sed \
-e '1,/^=====\+$$/d' \
-e '/^=====\+$$/d' \
J
|