|
From: Yin, H. <hu...@me...> - 2005-10-04 21:23:21
|
=20 > -----Original Message----- > From: val...@li...=20 > [mailto:val...@li...] On Behalf=20 > Of Robert Walsh > Sent: Tuesday, October 04, 2005 2:05 PM > To: Yin, Hui > Cc: val...@li... > Subject: Re: [Valgrind-users] suppression API support? >=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=20 > customers will be > > loaded into our software as shared libraries and=20 > get executed. > > If we use a suppresion file to suppress the error=20 > 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 > This isn't present in Valgrind at the moment, but I'd imagine=20 > it wouldn't be too difficult to add in via a new client=20 > request. Look in m_errormgr.c at=20 > load_one_suppressions_file() to see how suppressions are=20 > loaded. Add in a new entry point that adds a single=20 > suppression in the same way, add a new client request that=20 > calls this (look in m_scheduler/scheduler.c at=20 > do_client_request()) with, perhaps, a text string as an=20 > argument, and Bob's your uncle. >=20 > I imagine that your library initialization code would call this. >=20 > I'll look at doing something like this tonight or tomorrow=20 > night - way to busy at work at the moment. >=20 > Regards, > Robert. That'll be really great! Yes, our code would call this to add suppression information. I really appreciate your fast response. Hope this will benefit many other commercial users like us. Regards, --Hui >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads,=20 > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 |
|
From: Yin, H. <hu...@me...> - 2005-10-06 00:11:31
|
I have a follow-up question on this. How does valgrind control core compatibility with client request APIs? I noticed that there are some version checking between core and tools, but I didn't find any version information related to APIs in valgrind.h/memcheck.h. Specifically for this new suppression API, what would be the expected behavior if older version valgrind core is used on the executable containing the new API? Could you comment on these? Thanks and regards, --Hui PS. If needed I'll be happy to help testing the patch for this support. >=20 > This isn't present in Valgrind at the moment, but I'd imagine=20 > it wouldn't be too difficult to add in via a new client=20 > request. Look in m_errormgr.c at=20 > load_one_suppressions_file() to see how suppressions are=20 > loaded. Add in a new entry point that adds a single=20 > suppression in the same way, add a new client request that=20 > calls this (look in m_scheduler/scheduler.c at=20 > do_client_request()) with, perhaps, a text string as an=20 > argument, and Bob's your uncle. >=20 > I imagine that your library initialization code would call this. >=20 > I'll look at doing something like this tonight or tomorrow=20 > night - way to busy at work at the moment. >=20 > Regards, > Robert. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads,=20 > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 |
|
From: Robert W. <rj...@du...> - 2005-10-06 02:21:20
|
> I have a follow-up question on this. How does valgrind control core > compatibility with client request APIs? I noticed that there are some > version checking between core and tools, but I didn't find any version > information related to APIs in valgrind.h/memcheck.h. Specifically for > this new suppression API, what would be the expected behavior if older > version valgrind core is used on the executable containing the new API? > Could you comment on these? I think it just spits out a warning, but I don't recall off the top of my head. BTW: I haven't had any time to work on this, and probably won't be able to until the weekend. Also, after the patch is ready, it has to receive approval to be integrated into the main tree, which is not guaranteed. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |