On Thu, 2013-03-14 at 13:47 -0700, John Reiser wrote: > In the NEWS section, Release 3.8.0 (10 August 2012), TOOL CHANGES, > * Non-libc malloc implementations are now supported. This is useful > for tools that replace malloc (Memcheck, Massif, DRD, Helgrind). > Using the new option --soname-synonyms, such tools can be informed > that the malloc implementation is either linked statically into the > executable, or is present in some other shared library different > from libc.so. This makes it possible to process statically linked > programs, and programs using other malloc libraries, for example > TCMalloc or JEMalloc. > > So valgrind-3.8.0 says that it can handle static linking of malloc, > but the user must help. A little addition: the user must help if malloc is statically linked. However, at least at this moment, the application cannot be *fully* statically linked. The reason is that the Valgrind code that triggers the replacement is itself a shared object, which is LD_PRELOAD-ed. I still have on my list of things to do in low priority to see if this last limitation can be bypassed. For example, if the tool detects that the replacement code was not PRELOADED-ed, then the tool might mmap the code rwx. This trick might help fully static executable to be better supported.
At this stage, just a brainstorming idea that will probably explode in pieces once looked at more in depth. Philippe ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
