|
From: Philippe W. <phi...@sk...> - 2013-05-16 20:47:25
|
On Thu, 2013-05-16 at 22:14 +0200, Roland Mainz wrote: > On Thu, May 16, 2013 at 9:13 PM, Philippe Waroquiers > > However, the impact of this part is not as easy. > > I know... I studied the valgrind code in the meantime and started to > gnaw my fingernails off... ;-/ > > > This implies to change the basic way the malloc interception is done, > > by adding an additional "grouping" parameter, and store this in each > > memory "chunk" managed by memcheck. > > More impact on memory, and on the interface between the core and > > the tools replacing the malloc, and a lot more difficult to make > > "generic". > > I suspect this will imply also some possibly heavy changes to > > the "core" redirection logic. > > Right... but some day it needs to be done... ;-/ > ... for AFAIK (at least) two reasons: For sure, the below are valid reasons. But there is a balance between the additional complexity/cpu/memory in Valgrind versus the possible use. Valgrind already provides client requests which allows to instrument "mempool" libraries to have (some) support of bug detection by memcheck. Note that this support provides less bug detection capabilities than the replacement of the "standard" malloc/free/... but it looks unclear to me how to e.g. properly add redzone, freelist, etc to mempools. So, it looks unlikely to me that the mempool support can be made much better than what is provided by the *MEMPOOL* client requests in valgrind.h include file. For what concerns mixing chicken malloc and pterodactylus free: interesting functionality, but again IMO, the balance cost/benefit is not clear. The balance cost/benefit of a generalised --soname-synonyms looks however better to me. I might take the time to look at this. This would allow any redirection (e.g. the pthread redirections for helgrind or drd) to have synonyms, allowing e.g. these tools to work with static libraries. Philippe |