|
From: Yeshurun, M. <mei...@in...> - 2005-07-29 16:50:53
|
Hi,=20
=20
When using a PIE Valgrind (on a 64 bit platform), I get the crash even
earlier:
=20
VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes
failed.
VG_(get_memory_from_mmap): 221937856 bytes already allocated.
=20
(before that I also get an mmap failed warning on one of the .so's that
says no debug information or symbols were loaded)
=20
I googled this error and saw that someone suggested the following:
=20
=20
The crude hack is to change in coregrind/vg_main.c=20
case AT_PHDR:=20
VG_(valgrind_base) =3D PGROUNDDN(auxv->u.a_val);=20
break;=20
to=20
case AT_PHDR:=20
VG_(valgrind_base) =3D 0xa0000000; /* boooo! */=20
break
=20
Is this a good idea?
=20
(When using the non-PIE version Valgrind runs longer but I eventually
get a C++ bad_alloc exception.)
=20
=20
Any comments or suggestions would be appreciated.
=20
=20
Thanks,
=20
Meir
|
|
From: Tom H. <to...@co...> - 2005-07-29 17:02:10
|
In message <942...@ha...>
"Yeshurun, Meir" <mei...@in...> wrote:
> I googled this error and saw that someone suggested the following:
>
> The crude hack is to change in coregrind/vg_main.c
>
> case AT_PHDR:
> VG_(valgrind_base) = PGROUNDDN(auxv->u.a_val);
> break;
>
> to
>
> case AT_PHDR:
> VG_(valgrind_base) = 0xa0000000; /* boooo! */
> break
I think that will pretty much entirely defeat the purpose of using
the PIE build... You might as well just not bother.
> Is this a good idea?
Not really, you're forcing valgrind to load at an address in the
lower 2Gb of memory so you're back to having the same sort of
address space limitations as the non-PIE build.
Actually, what you're doing is slightly more wierd than that because
valgrind itself will still be loaded at a high address but the client
program will be limited to using memory below 0xa0000000.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-07-29 19:18:22
|
In message <942...@ha...>
"Yeshurun, Meir" <mei...@in...> wrote:
> When using a PIE Valgrind (on a 64 bit platform), I get the crash even
> earlier:
>
> VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed.
> VG_(get_memory_from_mmap): 221937856 bytes already allocated.
Could we see the full output please, with -v, so I can see where it
is getting to before it fails. The output from strace would probably
be helpful as well.
> (before that I also get an mmap failed warning on one of the .so's that
> says no debug information or symbols were loaded)
Probably because of a lack of address space.
> I googled this error and saw that someone suggested the following:
>
> The crude hack is to change in coregrind/vg_main.c
>
> case AT_PHDR:
> VG_(valgrind_base) = PGROUNDDN(auxv->u.a_val);
> break;
>
> to
>
> case AT_PHDR:
> VG_(valgrind_base) = 0xa0000000; /* boooo! */
> break
>
> Is this a good idea?
I've looked at this again and I think he is trying to give valgrind
more address space so it can load larger libraries to read the debug
information.
The correct way to do that for a PIE build is to change line 272 of
stage1.c and adjust the offset it applies (currently 0x2000000) to
exe_end to calculate exe_base. If you increase that value you should
give more space to valgrind but on a 64 bit platform with a PIE build
there should be plenty to go around.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|