|
From: Lifshitz, Y. <yai...@in...> - 2004-02-29 12:06:31
|
> Hi,
>=20
> I'm interested in writing a new skin around valgrind that will enable
> comprehensive memory profiling.
>=20
> I haven't found many profiling tools, and one I found (MemProf)
> crashes on our code.
> Also, our tool has a lot of dependencies on IS tools. This is a
> problem since many people here use allocators, and rebuilding
> everything from scratch without them can be very unfun :).
>=20
> My skin basically enables wrapping any function the user chooses. I
> then do 2 things:
>=20
> 1. Save the stack.
> 2. Analyze the sources to understand which class has just been
> allocated, if any.
>=20
> This means I can also detail how much objects of each class exist.
>=20
> For example, a user can write a config similar to this:
>=20
> {
> alloc_fun: allocator<T>::allocate(n);
> alloced =3D sizeof(T)*n;
> }
>=20
> {
> dealloc_fun: allocator<T>::allocate(n);
> dealloced =3D sizeof(T)*n;
> }
>=20
> or use wildcards, etc.
>=20
> This way we can analyze our memory usage without having horrible
> compilations.
> It seems to me like this might be worth getting into the core too
> perhaps: the ability to override allocation functions, so instead of
> re-compiling everything, I'll just instruct valgrind to do this:
>=20
> {
> func: allocate(n)
> replace_by: malloc(n)
> }
>=20
> Unless of course I want to debug my allocators.. :)
>=20
> At any rate, I'm trying to read the values passed to the allocate(..)
> function by doing the following code:
>=20
> // ebp address
> Addr ebp =3D (Addr)(VG_(baseBlock)[VGOFF_(m_ebp)]);
> Addr eip =3D ((Uint*)ebp)[1];
> int first_var =3D ((Uint*)ebp)[2];
>=20
> This code is similar to what happens in VG_(get_ExeContext2), so I
> cannot see why it doesn't work.
> I do notice however that ebp, eip are correct, but first_var always
> equals one.
>=20
> Can anyone direct me how to obtain its value? Perhaps it can be done
> during instrumentation (I'm currently doing it when my hook is called
> at the function entry)?
>=20
>=20
> Thanks,
>=20
> Yair
>=20
|
|
From: <sun...@t2...> - 2004-02-29 12:12:35
Attachments:
unnamed
|
Hi,
I'm interested in writing a new skin around valgrind that will enable
comprehensive memory profiling.
I haven't found many profiling tools, and one I found (MemProf)
crashes on our code.
Also, our tool has a lot of dependencies on IS tools. This is a problem s=
ince
many people here use allocators, and rebuilding everything from scratch w=
ithout
them can be very unfun :).
My skin basically enables wrapping any function the user chooses. I then =
do 2
things:
1. Save the stack.
2. Analyze the sources to understand which class has just been allocated,=
if
any.
This means I can also detail how much objects of each class exist.
=20
For example, a user can write a config similar to this:
{
alloc_fun: allocator<T>::allocate(n);
alloced =3D sizeof(T)*n;
}
{
dealloc_fun: allocator<T>::allocate(n);
dealloced =3D sizeof(T)*n;
}
or use wildcards, etc.
This way we can analyze our memory usage without having horrible compilat=
ions.
It seems to me like this might be worth getting into the core too perhaps=
: the
ability to override allocation functions, so instead of re-compiling
everything, I'll just instruct valgrind to do this:
{
func: allocate(n)
replace_by: malloc(n)
}
Unless of course I want to debug my allocators.. :)
At any rate, I'm trying to read the values passed to the allocate(..)
function by doing the following code:
// ebp address
Addr ebp =3D (Addr)(VG_(baseBlock)[VGOFF_(m_ebp)]);
Addr eip =3D ((Uint*)ebp)[1];
int first_var =3D ((Uint*)ebp)[2];
This code is similar to what happens in VG_(get_ExeContext2), so I
cannot see why it doesn't work.
I do notice however that ebp, eip are correct, but first_var always
equals one.
Can anyone direct me how to obtain its value? Perhaps it can be done
during instrumentation (I'm currently doing it when my hook is called
at the function entry)?
Thanks,
Yair
----- End forwarded message -----
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-01 10:08:28
|
On Sun, 29 Feb 2004 sun...@t2... wrote: > I'm interested in writing a new skin around valgrind that will enable > comprehensive memory profiling. > > I haven't found many profiling tools, and one I found (MemProf) > crashes on our code. You could try Massif, the new heap-profiling tool that's included in Valgrind's CVS, and will be included in 2.1.1 when it comes out. Your idea of wrapping functions is interesting. Massif has some facilities for 'drilling down' through stack traces, and also ignoring certain functions that are just wrappers for malloc/new/new[]. Your scheme sounds more powerful in general, though. N |