You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Nicholas S. <nic...@cs...> - 2003-12-23 11:45:22
|
Hi,
I sent this to the users' list a little while ago, but it might be better
answered by a valgrind developer.
I've been trying to get a valgrind skin i'm tinkering with to get a
program to report whenever it calls or returns from a function. However,
I'm getting some really wierd data. This is the instrumentation:
UCodeBlock* SK_(instrument)(UCodeBlock* cb, Addr a){
UCodeBlock *newCb;
Int i;
UInstr* u;
newCb=VG_(setup_UCodeBlock)(cb);
if (VG_(get_fnname_if_entry)(a, name, 100)){
if (VG_(get_filename_linenum)(a, file, 100,&line)){
VG_(call_helper_0_0)(newCb, (Addr) & printNameAndInfo);
}else {
VG_(call_helper_0_0)(newCb, (Addr) & printName);
}
}
for (i = 0; i < VG_(get_num_instrs)(cb); i++) {
u = VG_(get_instr)(cb, i);
if (((u->opcode) == JMP) &&
((u->jmpkind)==JmpRet) )
{
VG_(get_fnname)(a, name, 100); // hopefully always works?
VG_(call_helper_0_0)(newCb, (Addr) &printRet);
}
if (((u->opcode) == JMP) &&
((u->jmpkind)==JmpCall) )
{
VG_(get_fnname)(a, name, 100); // hopefully always works?
VG_(call_helper_0_0)(newCb, (Addr) &printCall);
}
VG_(copy_UInstr)(newCb, u);
}
VG_(free_UCodeBlock)(cb);
return newCb;
}
For the following program:
int main(int argc, char **argv){
a();
b();
return 0;
}
void a(){
printf("in a\n");
};
int b(){
printf("in b\n");
return 1;
};
we start with
CALL from __libc_start_main
main @ a.c LINE 6
CALL from main
a @ a.c LINE 13
Which is good. All execution inside the program seems to be fine
as long as no library functions are called ;) However, a() calls a
library
function, and I get told:
CALL from a
CALL from a
CALL from a
RET from a
CALL from a
a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
CALL from a
RET from a
RET from a
RET from a
RET from a
RET from a
_IO_printf
CALL from _IO_printf
...
And then a whole load of stuff inside libc, which I can't easily verify
as
correct or incorrect atm.
I just tried this again and setting LD_BIND_NOW=1 seems to cause the
calling of a() to behave as expected, and a lot of other junk to
disappear, but b() is still the same. (loads of "CALL" and "RET"
statements spewed out saying that they're at the address of the entry
point of the function, according to the %eip as reported by valgrind)
Am I misunderstanding something about UCode or what? I'm sure this is a
solved problem,
since I imagine every single skin would depend on the behavior that I am
hoping for (one
call of the instrumentation code for every call/ret).
Thanks a million,
Nick
|
|
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
|
|
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: 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: John C. <joh...@ta...> - 2003-12-23 01:47:12
|
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: 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: Jeremy F. <je...@go...> - 2003-12-23 01:15:34
|
CVS commit by fitzhardinge:
Make sure we use gcc's ld, not whatever random ld we happen to find in the path.
M +1 -1 Makefile.am 1.3
--- 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' \
|
|
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: 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: Julian S. <js...@ac...> - 2003-12-22 22:54:10
|
CVS commit by jseward:
De-anonymise a union so as to un-break compilation on gcc-2.95.
M +11 -11 vg_proxylwp.c 1.10
--- valgrind/coregrind/vg_proxylwp.c #1.9:1.10
@@ -197,5 +197,5 @@ struct PX_Reply {
Int syscallno; /* system call completed */
vki_ksiginfo_t siginfo; /* signal */
- };
+ } u;
};
@@ -512,5 +512,5 @@ static Int proxylwp(void *v)
sigreply.tid = px->tid;
sigreply.req = PX_Signal;
- sigreply.siginfo = px->siginfo;
+ sigreply.u.siginfo = px->siginfo;
if (!send_reply(&sigreply)) {
@@ -554,5 +554,5 @@ static Int proxylwp(void *v)
non-restartable syscalls? Does it matter?
*/
- reply.syscallno = tst->syscallno;
+ reply.u.syscallno = tst->syscallno;
tst->m_eax = -VKI_ERESTARTSYS;
@@ -599,5 +599,5 @@ static Int proxylwp(void *v)
reply should already be set up, including return in eax. */
vg_assert(reply.req == PX_RunSyscall);
- vg_assert(reply.syscallno == tst->syscallno);
+ vg_assert(reply.u.syscallno == tst->syscallno);
vg_assert(tst->status == VgTs_WaitSys);
px->state = PXS_IntReply;
@@ -608,5 +608,5 @@ static Int proxylwp(void *v)
back. */
vg_assert(reply.req == PX_RunSyscall);
- vg_assert(reply.syscallno == tst->syscallno);
+ vg_assert(reply.u.syscallno == tst->syscallno);
px->state = PXS_IntReply;
break;
@@ -712,5 +712,5 @@ static Int proxylwp(void *v)
/* Run a syscall for our thread; results will be poked
back into tst */
- reply.syscallno = tst->syscallno;
+ reply.u.syscallno = tst->syscallno;
vg_assert(px->state == PXS_WaitReq ||
@@ -723,5 +723,5 @@ static Int proxylwp(void *v)
*/
px_printf("RunSyscall in SigACK: rejecting syscall %d with ERESTARTSYS\n",
- reply.syscallno);
+ reply.u.syscallno);
tst->m_eax = -VKI_ERESTARTSYS;
} else {
@@ -1151,5 +1151,5 @@ static void sys_wait_results(Bool block,
tst->tid, tst->status);
- vg_assert(res.syscallno == tst->syscallno);
+ vg_assert(res.u.syscallno == tst->syscallno);
vg_assert(tst->status == VgTs_WaitSys);
@@ -1160,10 +1160,10 @@ static void sys_wait_results(Bool block,
if (VG_(clo_trace_signals) || VG_(clo_trace_syscalls))
VG_(message)(Vg_DebugMsg, "sys_wait_results: got PX_Signal for TID %d, signal %d",
- res.tid, res.siginfo.si_signo);
+ res.tid, res.u.siginfo.si_signo);
- vg_assert(res.siginfo.si_signo != 0);
+ vg_assert(res.u.siginfo.si_signo != 0);
if (VG_(threads)[res.tid].proxy &&
!VG_(threads)[res.tid].proxy->terminating)
- VG_(deliver_signal)(res.tid, &res.siginfo, True);
+ VG_(deliver_signal)(res.tid, &res.u.siginfo, True);
break;
|
|
From: Julian S. <js...@ac...> - 2003-12-22 22:39:44
|
CVS commit by jseward:
Add an implementation of strnlen for memcheck, from Tom Hughes.
M +2 -0 coregrind/vg_symtab2.c 1.71
M +7 -0 memcheck/mac_replace_strmem.c 1.11
--- valgrind/coregrind/vg_symtab2.c #1.70:1.71
@@ -2200,4 +2200,6 @@ void VG_(setup_code_redirect_table) ( vo
VG_(add_redirect_sym)("soname:libc.so.6", "stpcpy",
"*vgpreload_memcheck.so*", "stpcpy");
+ VG_(add_redirect_sym)("soname:libc.so.6", "strnlen",
+ "*vgpreload_memcheck.so*", "strnlen");
VG_(add_redirect_sym)("soname:ld-linux.so.2", "stpcpy",
--- valgrind/memcheck/mac_replace_strmem.c #1.10:1.11
@@ -177,4 +177,11 @@ char* strncat ( char* dst, const char* s
}
+unsigned int strnlen ( const char* str, unsigned int n )
+{
+ UInt i = 0;
+ while (i < n && str[i] != 0) i++;
+ return i;
+}
+
unsigned int strlen ( const char* str )
{
|
|
From: Julian S. <js...@ac...> - 2003-12-22 22:32:46
|
CVS commit by jseward:
Add overlap checking for stpcpy().
M +19 -12 mac_replace_strmem.c 1.10
--- valgrind/memcheck/mac_replace_strmem.c #1.9:1.10
@@ -321,19 +321,25 @@ int memcmp ( const void *s1V, const void
}
-/* glibc-2.3.2/sysdeps/generic/stpcpy.c */
-/* Copy SRC to DEST, returning the address of the terminating '\0' in DEST. */
-char *
-stpcpy (dest, src)
- char *dest;
- const char *src;
+
+/* Copy SRC to DEST, returning the address of the terminating '\0' in
+ DEST. (minor variant of strcpy) */
+
+char* stpcpy ( char* dst, const char* src )
{
- register char *d = dest;
- register const char *s = src;
+ const Char* src_orig = src;
+ Char* dst_orig = dst;
- do
- *d++ = *s;
- while (*s++ != '\0');
+ while (*src) *dst++ = *src++;
+ *dst = 0;
- return d - 1;
+ /* This checks for overlap after copying, unavoidable without
+ pre-counting length... should be ok */
+ if (is_overlap(dst_orig,
+ src_orig,
+ (Addr)dst-(Addr)dst_orig+1,
+ (Addr)src-(Addr)src_orig+1))
+ complain2("stpcpy", dst_orig, src_orig);
+
+ return dst;
}
|
|
From: Jeremy F. <je...@go...> - 2003-12-22 10:58:38
|
CVS commit by fitzhardinge:
Fixed munmap bug - split_segment wasn't updating the lengths properly.
Turn off debug printing.
M +15 -14 coregrind/vg_memory.c 1.48
M +17 -5 none/tests/map_unmap.c 1.2 [POSSIBLY UNSAFE: printf,system]
--- valgrind/coregrind/vg_memory.c #1.47:1.48
@@ -142,4 +142,5 @@ Segment *VG_(split_segment)(Addr a)
ns->offset += delta;
ns->len -= delta;
+ s->len = delta;
if (s->filename != NULL)
@@ -160,5 +161,5 @@ void VG_(unmap_range)(Addr addr, UInt le
Segment *s;
Segment *next;
- static const Bool debug = True || mem_debug;
+ static const Bool debug = False || mem_debug;
Addr end;
@@ -207,22 +208,12 @@ void VG_(unmap_range)(Addr addr, UInt le
if (debug)
VG_(printf)(" case 1: s->len=%d\n", s->len);
- } else if (addr <= s->addr && end >= seg_end) {
- /* this segment is completely contained within [addr, addr+len)
- -> delete segment
- */
- Segment *rs = VG_(SkipList_Remove)(&sk_segments, &s->addr);
- vg_assert(rs == s);
- freeseg(s);
-
- if (debug)
- VG_(printf)(" case 2: s==%p deleted\n", s);
} else if (addr <= s->addr && end > s->addr && end < seg_end) {
/* this segment's head is truncated by [addr, addr+len)
-> truncate head
*/
- Int delta = (addr+len) - s->addr;
+ Int delta = end - s->addr;
if (debug)
- VG_(printf)(" case 3: s->addr=%p s->len=%d delta=%d\n", s->addr, s->len, delta);
+ VG_(printf)(" case 2: s->addr=%p s->len=%d delta=%d\n", s->addr, s->len, delta);
s->addr += delta;
@@ -231,4 +222,14 @@ void VG_(unmap_range)(Addr addr, UInt le
vg_assert(s->len != 0);
+ } else if (addr <= s->addr && end >= seg_end) {
+ /* this segment is completely contained within [addr, addr+len)
+ -> delete segment
+ */
+ Segment *rs = VG_(SkipList_Remove)(&sk_segments, &s->addr);
+ vg_assert(rs == s);
+ freeseg(s);
+
+ if (debug)
+ VG_(printf)(" case 3: s==%p deleted\n", s);
} else if (addr > s->addr && end < seg_end) {
/* [addr, addr+len) is contained within a single segment
@@ -489,7 +490,7 @@ void VG_(mprotect_range)(Addr a, UInt le
Addr VG_(find_map_space)(Addr addr, UInt len, Bool for_client)
{
+ static const Bool debug = False || mem_debug;
Segment *s;
Addr ret;
- static const Bool debug = False || mem_debug;
Addr limit = (for_client ? VG_(client_end) : VG_(valgrind_mmap_end));
--- valgrind/none/tests/map_unmap.c #1.1:1.2
@@ -27,7 +27,8 @@ static void nibblemap(void *p)
int i;
- off = (random() & ~0x1fff) % LEN;
+ off = (random() % LEN) & ~(pagesize-1);
for(i = 0; i < PAGES; i++) {
+ /* printf("unmapping off=%d\n", off/pagesize); */
munmap((char *)p + off, pagesize);
off += 619*pagesize;
@@ -36,4 +37,12 @@ static void nibblemap(void *p)
}
+static void prmaps()
+{
+ char buf[100];
+ sprintf(buf, "/bin/cat /proc/%d/maps", getpid());
+ system(buf);
+ exit(1);
+}
+
int main()
{
@@ -52,12 +62,14 @@ int main()
m1 = domap();
if (m1 != expect1) {
- printf("FAIL: m=%p expect=%p\n",
- m1, expect1);
+ printf("FAIL i=%d: m1=%p expect1=%p\n",
+ i, m1, expect1);
+ prmaps();
return 1;
}
m2 = domap();
if (m2 != expect2) {
- printf("FAIL: m=%p expect=%p\n",
- m2, expect2);
+ printf("FAIL i=%d: m2=%p expect2=%p\n",
+ i, m2, expect2);
+ prmaps();
return 1;
}
|
|
From: Tom H. <th...@cy...> - 2003-12-22 10:46:55
|
In message <200...@of...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Fix nasty use after free bug revealed by last munmap fix.
> Unexport split_segment; it isn't needed elsewhere.
> (Something still wrong with munmap.)
I'd just found that and was about to report it ;-)
> - static const Bool debug = False || mem_debug;
> - Addr end = addr+len;
> + static const Bool debug = True || mem_debug;
> + Addr end;
Did you actually mean to commit that?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-22 10:43:31
|
CVS commit by fitzhardinge:
Fix nasty use after free bug revealed by last munmap fix.
Unexport split_segment; it isn't needed elsewhere.
(Something still wrong with munmap.)
M +0 -1 vg_include.h 1.163
M +18 -11 vg_memory.c 1.47
M +1 -2 vg_symtab2.c 1.70
--- valgrind/coregrind/vg_include.h #1.162:1.163
@@ -1581,5 +1581,4 @@ extern Addr VG_(find_map_space)(Addr bas
extern Segment *VG_(find_segment)(Addr a);
extern Segment *VG_(next_segment)(Segment *);
-extern Segment *VG_(split_segment)(Addr a);
extern Bool VG_(seg_contains)(const Segment *s, Addr ptr, UInt size);
--- valgrind/coregrind/vg_memory.c #1.46:1.47
@@ -143,4 +143,7 @@ Segment *VG_(split_segment)(Addr a)
ns->len -= delta;
+ if (s->filename != NULL)
+ ns->filename = VG_(arena_strdup)(VG_AR_CORE, s->filename);
+
if (ns->symtab != NULL)
VG_(symtab_incref)(ns->symtab);
@@ -157,15 +160,17 @@ void VG_(unmap_range)(Addr addr, UInt le
Segment *s;
Segment *next;
- static const Bool debug = False || mem_debug;
- Addr end = addr+len;
+ static const Bool debug = True || mem_debug;
+ Addr end;
if (len == 0)
return;
+ len = PGROUNDUP(len);
+ vg_assert(addr == PGROUNDDN(addr));
+
if (debug)
VG_(printf)("unmap_range(%p, %d)\n", addr, len);
- len = PGROUNDUP(addr+len)-PGROUNDDN(addr);
- addr = PGROUNDDN(addr);
+ end = addr+len;
/* Everything must be page-aligned */
@@ -183,5 +188,5 @@ void VG_(unmap_range)(Addr addr, UInt le
if (debug)
VG_(printf)("unmap: addr=%p-%p s=%p ->addr=%p-%p len=%d\n",
- addr, addr+len, s, s->addr, s->addr+s->len, s->len);
+ addr, end, s, s->addr, seg_end, s->len);
if (!VG_(seg_overlaps)(s, addr, len)) {
@@ -218,10 +223,12 @@ void VG_(unmap_range)(Addr addr, UInt le
Int delta = (addr+len) - s->addr;
+ if (debug)
+ VG_(printf)(" case 3: s->addr=%p s->len=%d delta=%d\n", s->addr, s->len, delta);
+
s->addr += delta;
s->offset += delta;
s->len -= delta;
- if (debug)
- VG_(printf)(" case 3: s->addr=%p s->len=%d delta=%d\n", s->addr, s->len, delta);
+ vg_assert(s->len != 0);
} else if (addr > s->addr && end < seg_end) {
/* [addr, addr+len) is contained within a single segment
@@ -246,6 +253,6 @@ void VG_(unmap_range)(Addr addr, UInt le
}
-/* If possible, merge segment with its neighbours - some segments,
- including s, may be destroyed in the process */
+/* Return true if two segments are adjacent and mergable (s1 is
+ assumed to have a lower ->addr than s2) */
static inline Bool neighbours(Segment *s1, Segment *s2)
{
@@ -274,6 +281,6 @@ static inline Bool neighbours(Segment *s
}
-/* Merge segments in the address range if they're adjacent and
- compatible */
+/* If possible, merge segment with its neighbours - some segments,
+ including s, may be destroyed in the process */
static void merge_segments(Addr a, UInt len)
{
--- valgrind/coregrind/vg_symtab2.c #1.69:1.70
@@ -1209,6 +1209,5 @@ SegInfo *VG_(read_seg_symbols) ( Segment
si->size = seg->len;
si->foffset = seg->offset;
- si->filename = VG_(arena_malloc)(VG_AR_SYMTAB, 1 + VG_(strlen)(seg->filename));
- VG_(strcpy)(si->filename, seg->filename);
+ si->filename = VG_(arena_strdup)(VG_AR_SYMTAB, seg->filename);
si->ref = 1;
|
|
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: Jeremy F. <je...@go...> - 2003-12-22 08:49:40
|
CVS commit by fitzhardinge:
Re-add proper support for mremap(). Also, fix a bug in munmap().
A none/tests/mremap.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A none/tests/mremap.stderr.exp 1.1
A none/tests/mremap.stdout.exp 1.1
A none/tests/mremap.vgtest 1.1
M +1 -0 coregrind/vg_include.h 1.162
M +20 -13 coregrind/vg_memory.c 1.46
M +180 -82 coregrind/vg_syscalls.c 1.72
M +4 -0 include/vg_kerneliface.h 1.10
M +3 -1 none/tests/Makefile.am 1.19
--- valgrind/coregrind/vg_include.h #1.161:1.162
@@ -1581,4 +1581,5 @@ extern Addr VG_(find_map_space)(Addr bas
extern Segment *VG_(find_segment)(Addr a);
extern Segment *VG_(next_segment)(Segment *);
+extern Segment *VG_(split_segment)(Addr a);
extern Bool VG_(seg_contains)(const Segment *s, Addr ptr, UInt size);
--- valgrind/coregrind/vg_memory.c #1.45:1.46
@@ -115,6 +115,6 @@ static void freeseg(Segment *s)
}
-/* Split a segment at address a */
-static Segment *split_segment(Addr a)
+/* Split a segment at address a, returning the new segment */
+Segment *VG_(split_segment)(Addr a)
{
Segment *s = VG_(SkipList_Find)(&sk_segments, &a);
@@ -158,4 +158,5 @@ void VG_(unmap_range)(Addr addr, UInt le
Segment *next;
static const Bool debug = False || mem_debug;
+ Addr end = addr+len;
if (len == 0)
@@ -175,4 +176,5 @@ void VG_(unmap_range)(Addr addr, UInt le
s != NULL && s->addr < (addr+len);
s = next) {
+ Addr seg_end = s->addr + s->len;
/* fetch next now in case we end up deleting this segment */
@@ -180,12 +182,17 @@ void VG_(unmap_range)(Addr addr, UInt le
if (debug)
- VG_(printf)("unmap: addr=%p s=%p ->addr=%p len=%d end=%p\n",
- addr, s, s->addr, s->len, s->addr+s->len);
+ VG_(printf)("unmap: addr=%p-%p s=%p ->addr=%p-%p len=%d\n",
+ addr, addr+len, s, s->addr, s->addr+s->len, s->len);
- if (!VG_(seg_overlaps)(s, addr, len))
+ if (!VG_(seg_overlaps)(s, addr, len)) {
+ if (debug)
+ VG_(printf)(" (no overlap)\n");
continue;
+ }
/* 4 cases: */
- if (addr > s->addr && addr < (s->addr + s->len)) {
+ if (addr > s->addr &&
+ addr < seg_end &&
+ end >= seg_end) {
/* this segment's tail is truncated by [addr, addr+len)
-> truncate tail
@@ -195,5 +202,5 @@ void VG_(unmap_range)(Addr addr, UInt le
if (debug)
VG_(printf)(" case 1: s->len=%d\n", s->len);
- } else if (addr <= s->addr && (addr+len) >= (s->addr + s->len)) {
+ } else if (addr <= s->addr && end >= seg_end) {
/* this segment is completely contained within [addr, addr+len)
-> delete segment
@@ -205,5 +212,5 @@ void VG_(unmap_range)(Addr addr, UInt le
if (debug)
VG_(printf)(" case 2: s==%p deleted\n", s);
- } else if ((addr+len) > s->addr && (addr+len) < (s->addr+s->len)) {
+ } else if (addr <= s->addr && end > s->addr && end < seg_end) {
/* this segment's head is truncated by [addr, addr+len)
-> truncate head
@@ -217,5 +224,5 @@ void VG_(unmap_range)(Addr addr, UInt le
if (debug)
VG_(printf)(" case 3: s->addr=%p s->len=%d delta=%d\n", s->addr, s->len, delta);
- } else if (addr > s->addr && (addr+len) < (s->addr + s->len)) {
+ } else if (addr > s->addr && end < seg_end) {
/* [addr, addr+len) is contained within a single segment
-> split segment into 3, delete middle portion
@@ -223,6 +230,6 @@ void VG_(unmap_range)(Addr addr, UInt le
Segment *middle, *rs;
- middle = split_segment(addr);
- split_segment(addr+len);
+ middle = VG_(split_segment)(addr);
+ VG_(split_segment)(addr+len);
vg_assert(middle->addr == addr);
@@ -456,6 +463,6 @@ void VG_(mprotect_range)(Addr a, UInt le
vg_assert((len & (VKI_BYTES_PER_PAGE-1)) == 0);
- split_segment(a);
- split_segment(a+len);
+ VG_(split_segment)(a);
+ VG_(split_segment)(a+len);
for(s = VG_(SkipList_Find)(&sk_segments, &a);
--- valgrind/coregrind/vg_syscalls.c #1.71:1.72
@@ -118,4 +118,40 @@ static void do_atfork_child(ThreadId tid
}
+/* return true if address range entirely contained within client
+ address space */
+static Bool valid_client_addr(Addr start, UInt size, ThreadId tid, const Char *syscall)
+{
+ Addr end = start+size;
+ Addr cl_base = VG_(client_base);
+ Bool ret;
+
+ if (size == 0)
+ return True;
+
+ if (cl_base < 0x10000)
+ cl_base = 0x10000;
+
+ ret =
+ (end >= start) &&
+ start >= cl_base && start < VG_(client_end) &&
+ (end <= VG_(client_end));
+
+ if (0)
+ VG_(printf)("%s: test=%p-%p client=%p-%p ret=%d\n",
+ syscall, start, end, cl_base, VG_(client_end), ret);
+
+ if (!ret && syscall != NULL) {
+ VG_(message)(Vg_UserMsg, "Warning: client syscall %s tried to modify addresses %p-%p",
+ syscall, start, end);
+
+ if (VG_(clo_verbosity) > 1) {
+ ExeContext *ec = VG_(get_ExeContext)(tid);
+ VG_(pp_ExeContext)(ec);
+ }
+ }
+
+ return ret;
+}
+
/* ---------------------------------------------------------------------
Doing mmap, munmap, mremap, mprotect
@@ -163,7 +199,7 @@ void mmap_segment ( Addr a, UInt len, UI
VG_(map_fd_segment)(a, len, prot, flags, fd, offset, NULL);
- rr = prot & PROT_READ;
- ww = prot & PROT_WRITE;
- xx = prot & PROT_EXEC;
+ rr = prot & VKI_PROT_READ;
+ ww = prot & VKI_PROT_WRITE;
+ xx = prot & VKI_PROT_EXEC;
VG_TRACK( new_mem_mmap, a, len, rr, ww, xx );
@@ -196,7 +232,7 @@ void mprotect_segment ( Addr a, UInt len
VG_(mprotect_range)(a, len, prot);
- rr = prot & PROT_READ;
- ww = prot & PROT_WRITE;
- xx = prot & PROT_EXEC;
+ rr = prot & VKI_PROT_READ;
+ ww = prot & VKI_PROT_WRITE;
+ xx = prot & VKI_PROT_EXEC;
// if removing exe permission, should check and remove from exe_seg list
@@ -208,32 +244,137 @@ void mprotect_segment ( Addr a, UInt len
static
-void mremap_segment ( Addr old_addr, UInt old_size, Addr new_addr,
- UInt new_size )
+Addr mremap_segment ( Addr old_addr, UInt old_size,
+ Addr new_addr, UInt new_size,
+ UInt flags, ThreadId tid)
{
- /* If the block moves, assume new and old blocks can't overlap; seems to
- * be valid judging from Linux kernel code in mm/mremap.c */
- vg_assert(old_addr == new_addr ||
- old_addr+old_size < new_addr ||
- new_addr+new_size < old_addr);
+ Addr ret;
+ Segment *seg, *next;
- if (new_size < old_size) {
- // if exe_seg
- // unmap old symbols from old_addr+new_size..old_addr+new_size
- // update exe_seg size = new_size
- // update exe_seg addr = new_addr...
- VG_TRACK( copy_mem_remap, old_addr, new_addr, new_size );
- VG_TRACK( die_mem_munmap, old_addr+new_size, old_size-new_size );
+ old_size = PGROUNDUP(old_size);
+ new_size = PGROUNDUP(new_size);
+
+ if (PGROUNDDN(old_addr) != old_addr)
+ return -VKI_EINVAL;
+
+ if (!valid_client_addr(old_addr, old_size, tid, "mremap(old_addr)"))
+ return -VKI_EFAULT;
+
+ /* fixed at the current address means we don't move it */
+ if ((flags & VKI_MREMAP_FIXED) && (old_addr == new_addr))
+ flags &= ~(VKI_MREMAP_FIXED|VKI_MREMAP_MAYMOVE);
+
+ if (flags & VKI_MREMAP_FIXED) {
+ if (PGROUNDDN(new_addr) != new_addr)
+ return -VKI_EINVAL;
+
+ if (!valid_client_addr(new_addr, new_size, tid, "mremap(new_addr)"))
+ return -VKI_ENOMEM;
+
+ /* check for overlaps */
+ if ((old_addr < (new_addr+new_size) &&
+ (old_addr+old_size) > new_addr) ||
+ (new_addr < (old_addr+new_size) &&
+ (new_addr+new_size) > old_addr))
+ return -VKI_EINVAL;
+ }
+
+ /* Do nothing */
+ if (!(flags & VKI_MREMAP_FIXED) && new_size == old_size)
+ return old_addr;
+
+ seg = VG_(find_segment)(old_addr);
+
+ /* range must be contained within segment */
+ if (seg == NULL || !VG_(seg_contains)(seg, old_addr, old_size))
+ return -VKI_EINVAL;
+
+ next = VG_(next_segment)(seg);
+
+ if (0)
+ VG_(printf)("mremap: old_addr+new_size=%p next->addr=%p flags=%d\n",
+ old_addr+new_size, next->addr, flags);
+
+ if ((flags & VKI_MREMAP_FIXED) ||
+ (next != NULL && (old_addr+new_size) > next->addr)) {
+ /* we're moving the block */
+ Addr a;
+
+ if ((flags & (VKI_MREMAP_FIXED|VKI_MREMAP_MAYMOVE)) == 0)
+ return -VKI_ENOMEM; /* not allowed to move */
+
+ if ((flags & VKI_MREMAP_FIXED) == 0)
+ new_addr = 0;
+
+ a = VG_(find_map_space)(new_addr, new_size, True);
+
+ if ((flags & VKI_MREMAP_FIXED) && a != new_addr)
+ return -VKI_ENOMEM; /* didn't find the place we wanted */
+
+ new_addr = a;
+ ret = a;
+ /* we've nailed down the location */
+ flags |= VKI_MREMAP_FIXED|VKI_MREMAP_MAYMOVE;
+
+ ret = VG_(do_syscall)(__NR_mremap, old_addr, old_size, new_size,
+ flags, new_addr);
+
+ if (ret != new_addr) {
+ vg_assert(VG_(is_kerror)(ret));
+ return ret;
+ }
+
+ VG_TRACK(copy_mem_remap, old_addr, new_addr,
+ (old_size < new_size) ? old_size : new_size);
+
+ if (new_size > old_size)
+ VG_TRACK(new_mem_mmap, new_addr+old_size, new_size-old_size,
+ seg->prot & VKI_PROT_READ,
+ seg->prot & VKI_PROT_WRITE,
+ seg->prot & VKI_PROT_EXEC);
+ VG_TRACK(die_mem_munmap, old_addr, old_size);
+
+ VG_(map_file_segment)(new_addr, new_size,
+ seg->prot,
+ seg->flags,
+ seg->dev, seg->ino,
+ seg->offset, seg->filename);
+
+ VG_(munmap)((void *)old_addr, old_size);
} else {
- // if exe_seg
- // map new symbols from new_addr+old_size..new_addr+new_size
- // update exe_seg size = new_size
- // update exe_seg addr = new_addr...
- VG_TRACK( copy_mem_remap, old_addr, new_addr, old_size );
- // what should the permissions on the new extended part be??
- // using 'rwx'
- VG_TRACK( new_mem_mmap, new_addr+old_size, new_size-old_size,
- True, True, True );
+ /* staying in place */
+ ret = old_addr;
+
+ if (new_size < old_size) {
+ VG_TRACK(die_mem_munmap, old_addr+new_size, old_size-new_size);
+ VG_(munmap)((void *)(old_addr+new_size), old_size-new_size);
+ } else {
+ /* we've nailed down the location */
+ flags &= ~VKI_MREMAP_MAYMOVE;
+
+ if (0)
+ VG_(printf)("mremap: old_addr=%p old_size=%d new_size=%d flags=%d\n",
+ old_addr, old_size, new_size, flags);
+
+ ret = VG_(do_syscall)(__NR_mremap, old_addr, old_size, new_size,
+ flags, 0);
+
+ if (ret != old_addr)
+ return ret;
+
+ VG_TRACK(new_mem_mmap, old_addr+old_size, new_size-old_size,
+ seg->prot & VKI_PROT_READ,
+ seg->prot & VKI_PROT_WRITE,
+ seg->prot & VKI_PROT_EXEC);
+
+ VG_(map_file_segment)(old_addr+old_size, new_size-old_size,
+ seg->prot,
+ seg->flags,
+ seg->dev, seg->ino,
+ seg->offset, seg->filename);
}
+ }
+
+ return ret;
}
@@ -847,40 +988,4 @@ static Addr do_brk(Addr newbrk)
-/* return true if address range entirely contained within client
- address space */
-static Bool valid_client_addr(Addr start, UInt size, ThreadId tid, const Char *syscall)
-{
- Addr end = start+size;
- Addr cl_base = VG_(client_base);
- Bool ret;
-
- if (size == 0)
- return True;
-
- if (cl_base < 0x10000)
- cl_base = 0x10000;
-
- ret =
- (end >= start) &&
- start >= cl_base && start < VG_(client_end) &&
- (end <= VG_(client_end));
-
- if (0)
- VG_(printf)("%s: test=%p-%p client=%p-%p ret=%d\n",
- syscall, start, end, cl_base, VG_(client_end), ret);
-
- if (!ret && syscall != NULL) {
- VG_(message)(Vg_UserMsg, "Warning: client syscall %s tried to modify addresses %p-%p",
- syscall, start, end);
-
- if (VG_(clo_verbosity) > 1) {
- ExeContext *ec = VG_(get_ExeContext)(tid);
- VG_(pp_ExeContext)(ec);
- }
- }
-
- return ret;
-}
-
/* ---------------------------------------------------------------------
Vet file descriptors for sanity
@@ -1365,13 +1470,9 @@ PRE(mremap)
{
/* void* mremap(void * old_address, size_t old_size,
- size_t new_size, unsigned long flags); */
- MAYBE_PRINTF("mremap ( %p, %d, %d, 0x%x )\n",
- arg1, arg2, arg3, arg4);
- SYSCALL_TRACK( pre_mem_write, tid, "mremap(old_address)", arg1, arg2 );
-}
+ size_t new_size, unsigned long flags, void * new_address); */
+ MAYBE_PRINTF("mremap ( %p, %d, %d, 0x%x, %p )\n",
+ arg1, arg2, arg3, arg4, arg5);
-POST(mremap)
-{
- mremap_segment( arg1, arg2, (Addr)res, arg3 );
+ res = mremap_segment((Addr)arg1, arg2, (Addr)arg5, arg3, arg4, tid);
}
@@ -2381,4 +2482,6 @@ PRE(ipc)
}
case 22: /* IPCOP_shmdt */
+ if (!valid_client_addr(arg1, 1, tid, "shmdt"))
+ res = -VKI_EINVAL;
break;
case 23: /* IPCOP_shmget */
@@ -2518,12 +2621,7 @@ POST(ipc)
case 22: /* IPCOP_shmdt */
{
- /* ### FIXME: this should call make_noaccess on the
- * area passed to shmdt. But there's no way to
- * figure out the size of the shared memory segment
- * just from the address... Maybe we want to keep a
- * copy of the exiting mappings inside valgrind? */
Segment *s = VG_(find_segment)(arg1);
- if (s->addr == arg1 && (s->flags & SF_SHM)) {
+ if (s != NULL && (s->flags & SF_SHM) && VG_(seg_contains)(s, arg1, 1)) {
VG_TRACK( die_mem_munmap, s->addr, s->len );
VG_(unmap_range)(s->addr, s->len);
@@ -4782,4 +4880,5 @@ static const struct sys_info special_sys
SYSB_(brk, False),
SYSB_(mmap, False),
+ SYSB_(mremap, False),
#if SIGNAL_SIMULATION
@@ -4829,5 +4928,4 @@ static const struct sys_info sys_info[]
SYSB_(chroot, False),
SYSB_(madvise, True),
- SYSBA(mremap, False),
SYSB_(nice, False),
SYSB_(setresgid32, False),
--- valgrind/include/vg_kerneliface.h #1.9:1.10
@@ -317,4 +317,8 @@ struct vki_ucontext {
#define VKI_MAP_CLIENT 0x80000000 /* internal pseudo-flag to distinguish client mappings */
+/* linux/mman.h */
+#define VKI_MREMAP_MAYMOVE 1
+#define VKI_MREMAP_FIXED 2
+
/* Copied from linux-2.4.19/include/asm-i386/fcntl.h */
--- valgrind/none/tests/Makefile.am #1.18:1.19
@@ -24,4 +24,5 @@
gxx304.stderr.exp gxx304.vgtest \
map_unmap.stdout.exp map_unmap.vgtest \
+ mremap.stdout.exp mremap.vgtest \
munmap_exe.stderr.exp munmap_exe.vgtest \
pth_blockedsig.stderr.exp \
@@ -43,5 +44,5 @@
args bitfield1 bt_everything bt_literal coolo_strlen \
cpuid dastest discard floored fork fpu_lazy_eflags \
- fucomip munmap_exe map_unmap rcl_assert \
+ fucomip munmap_exe map_unmap mremap rcl_assert \
rcrl readline1 resolv seg_override sha1_test shortpush shorts smc1 \
pth_blockedsig \
@@ -66,4 +67,5 @@
fucomip_SOURCES = fucomip.c
map_unmap_SOURCES = map_unmap.c
+mremap_SOURCES = mremap.c
munmap_exe_SOURCES = munmap_exe.c
rcl_assert_SOURCES = rcl_assert.S
|
|
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: 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: 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: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: 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: Julian S. <js...@ac...> - 2003-12-22 00:51:26
|
CVS commit by jseward:
resolve_redir(): when a redirect is resolved, if the source has
already been translated, discard that translation. Otherwise the
redirect will never take effect.
M +27 -3 vg_symtab2.c 1.69
--- valgrind/coregrind/vg_symtab2.c #1.68:1.69
@@ -2046,7 +2046,31 @@ static Bool resolve_redir(CodeRedirect *
}
- if (VG_(search_transtab)(redir->from_addr) != 0)
- VG_(message)(Vg_DebugMsg, "!!!! adding redirect to already called function %s (%p -> %p)!!!",
- redir->from_sym, redir->from_addr, redir->to_addr);
+ if (VG_(search_transtab)(redir->from_addr) != 0) {
+ /* For some given (from, to) redir, the "from" function got
+ called before the .so containing "to" became available. We
+ know this because there is already a translation for the
+ entry point of the original "from". So the redirect will
+ never actually take effect unless that translation is
+ discarded.
+
+ Note, we only really need to discard the first bb of the
+ old entry point, and so we avoid the problem of having to
+ figure out how big that bb was -- since it is at least 1
+ byte of original code, we can just pass 1 as the original
+ size to invalidate_translations() and it will indeed get
+ rid of the translation.
+
+ Note, this is potentially expensive -- discarding
+ translations causes complete unchaining.
+ */
+ if (VG_(clo_verbosity) > 2) {
+ VG_(message)(Vg_UserMsg,
+ "Discarding translation due to redirect of already called function" );
+ VG_(message)(Vg_UserMsg,
+ " %s (%p -> %p)",
+ redir->from_sym, redir->from_addr, redir->to_addr );
+ }
+ VG_(invalidate_translations)(redir->from_addr, 1, True);
+ }
VG_(SkipList_Insert)(&sk_resolved_redir, redir);
|