|
From: Yin, H. <hu...@me...> - 2005-10-04 20:42:26
|
Sorry, just noticed that I screwed up the subject line in previous post. ________________________________ From: val...@li... [mailto:val...@li...] On Behalf Of Yin, Hui Sent: Tuesday, October 04, 2005 1:21 PM To: val...@li... Subject: [Valgrind-users] opatch suppression support? =09 =09 I wonder whether it is possible for valgrind to take the suppression information via an api rather than via a suppression file. We are advocating the valgrind memcheck tool to our customer. All the user code from customers will be loaded into our software as shared libraries and get executed. If we use a suppresion file to suppress the error reports from our own code, then we have to ship suppression file to the customer. And we don't want to expose that information. It would be much desired if a valgrind api is available for adding suppression information from inside our software. Is this possible? =20 Is there other possible approach exploiting the fact that our own code and the user code have a clear boundary. All user code will be in the shared libraries. Is there an existing client request mechanism we can use to limit the memcheck or error report on shared libraries only? =20 I appreciate your help. =20 Regards, --Hui |
|
From: Robert W. <rj...@du...> - 2005-10-04 21:05:20
|
> I wonder whether it is possible for valgrind to take the > suppression information via an api rather than via a > suppression file. We are advocating the valgrind memcheck > tool to our customer. All the user code from customers will be > loaded into our software as shared libraries and get executed. > If we use a suppresion file to suppress the error reports from > our own code, then we have to ship suppression file to the > customer. And we don't want to expose that information. It > would be much desired if a valgrind api is available for > adding suppression information from inside our software. Is > this possible? This isn't present in Valgrind at the moment, but I'd imagine it wouldn't be too difficult to add in via a new client request. Look in m_errormgr.c at load_one_suppressions_file() to see how suppressions are loaded. Add in a new entry point that adds a single suppression in the same way, add a new client request that calls this (look in m_scheduler/scheduler.c at do_client_request()) with, perhaps, a text string as an argument, and Bob's your uncle. I imagine that your library initialization code would call this. I'll look at doing something like this tonight or tomorrow night - way to busy at work at the moment. Regards, Robert. |