On Thu, May 12, 2011 at 08:55:32AM -0700, John Reiser wrote:
> >>> FWIW this is a matter of 227Mb large /usr/lib/valgrind versus 71Mb without
> >>> debug.
> >>
> >> Which machine architecture and compiler?
> >
> > amd64 gcc, but indeed with -g, because it's how binaries are supposed to
> > be built in Debian.
>
> For many [most?] packages, Fedora handles this by building _with_ -g in
> CFLAGS,
> saving everything in a <package>-debuginfo-<version>.rpm, then [effectively]
> applying "strip --strip-debug" before constructing <package>-<version>.rpm.
> Ordinary installs get the smaller pieces without debuginfo, but the
> corresponding
> full -g is available for developers to use when handling bug reports.
> [However, in this specific case I cannot find a valgrind-debuginfo package.]
Debian does the same, mostly. And I plan to do the same. I'm just unsure
whether doing this will leave valgrind in a usable state or not. I think it
will I just wanted some confirmation.
> > By default, after build, debian strip:
> >
> > - libraries with:
> > strip --remove-section=.comment --remove-section=.note --strip-unnedded
> > - exectutables with:
> > strip --remove-section=.comment --remove-section=.note
> >
> > Would this be okay to do that? (I think so since my earlier test proves
> > it works).
>
> The earlier test checks only the 'free' routine, so applying --strip-unneeded
> would rely on all "interesting" routines having similar behavior.
Sure, though I fail to see why it would be any different for the other
ones. the vgpreload .so files define a bunch of symbols:
0000000000003890 T _vgrZU_libcZdsoZa_free
0000000000004c00 T _vgrZU_libcZdsoZa_index
0000000000002980 T _vgrZU_libcZdsoZa_mallinfo
0000000000004730 T _vgrZU_libcZdsoZa_malloc
0000000000002950 T _vgrZU_libcZdsoZa_malloc_get_state
0000000000002960 T _vgrZU_libcZdsoZa_malloc_set_state
0000000000002a60 T _vgrZU_libcZdsoZa_malloc_size
0000000000002970 T _vgrZU_libcZdsoZa_malloc_stats
0000000000002930 T _vgrZU_libcZdsoZa_malloc_trim
0000000000002b40 T _vgrZU_libcZdsoZa_malloc_usable_size
0000000000002920 T _vgrZU_libcZdsoZa_mallopt
and so forth, and obviously what will produce a proper stack is a way to find
out about those symbols which in my knowledge should still work with the way
Debian strips binaries.
I think I'll hence try to "mildly" strip the binaries and see where that
goes. With a warning to the users so that they know about what is
failing if something begins to fail miserably after that change.
> > If you strip --strip-debug (which basically should be the same as not
> > building with -g if I'm correct) then memcheck-amd64-linux here is:
> >
> > -rwxr-xr-x 1 madcoder madcoder 4751991 12 mai 17:06
> > /home/madcoder/memcheck-amd64-linux
> >
> > which is basically 4M instead of 11.5… du your /usr/lib/valgrind you'll see
> > it's huge!
>
> I see around 12MB per <tool>-amd64-linux, and about 5MB or less after "strip
> --strip-debug".
> If that much is too big, then consider removing infrequently-used tools,
> or mounting a compressed filesystem on /usr/lib/valgrind, or perhaps
> compressing
> individual executables with a compressor such as upx
> (http://upx.sourceforge.net).
> upx does compress them to about 2MB to 2.6MB each, and they do invoke; but
> valgrind
> and its tools might make assumptions about layout of address space that are
> more
> demanding than a usual executable program.
Please, it's too big because it's a BW waste for the mirrors and so
forth, plus it uses 200Mb where 60 are enough, yeah that's a waste,
that's with those kind of reasonings that you end up with needing 20G
for a decent system nowadays :/
--
·O· Pierre Habouzit
··O [email protected]
OOO http://www.madism.org
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
