Nick, Pls see inline for [VV] for clarification Thanx, -Venky > -----Original Message----- > From: Nicholas Nethercote [mailto:[email protected]] > Sent: Tuesday, June 23, 2009 8:28 PM > To: Venky Venkatesh (venky) > Cc: [email protected] > Subject: Re: [Valgrind-users] C++ function wrapping and other > questions > > On Wed, Jun 24, 2009 at 12:47 PM, Venky Venkatesh > (venky)<[email protected]> wrote: > > Nick, > > Thanks for the prompt response. > > I would very much like your input on one of the other > question in my > > original mail (reproduced below) -- I am looking for *any* > strategies > > to solve the problem at hand using valgrind: > > "#6. i noticed one of the caveats was the limited number of options > > available for calling the original function. is there a way > around it > > (since the system i have to test doesnt naturally fall in that > > restriction)? what i want to do is to use the wrapper > function under > > certain circumstances (controlled by user e.g. to inject faults i.e. > > failure/fault injection testing) and use the original function > > otherwise. with that in view i was planning to call the original > > function from the wrapper function (e.g. in the previous > example, when > > failure injection testing for this function was not being done) and > > was getting cramped by this caveat. what suggestions do you > have for > > getting around this problem?" > > I don't understand the question. You should be able to call > the original function from the wrapper, that's the whole > point. If this is inside an if-then-else it should still work AFAIK. >
[VV]: the original functions that I want to wrap (and call from the wrapper via an if-then-else) do not have the standard set of supported signatures (I mean the CALL_FN_*_*). With this limitation, I cannot call the original function from the wrapped function. So is there any other way I could get around this problem e.g. 1. Add any other means of calling the original function - not sure how hard it is add. -- OR -- 2. Install and remove the wrapper dynamically (so that the calls to original function can be suitably directed to the wrapper or the original) - if so can you point to information of how to do that? -- OR -- 3. Any entirely different valgrind method to accomplish the original goal of selective calling of wrapper and original functions (for the fault injection testing that I set out to do) - may be I am rat-holing using the wrong valgrind construct for the job. BTW, I am assuming that there is no limitation on the signature of the orignal function with regards to doing I_WRAP_SONAME_FNNAME_ZZ (as there are for CALL_FN_*_*) - the manual doesn't call out explicitly. > > Regarding C++, if I understand correctly, if I understand > the quirks > > of the compiler regarding how the source code maps to > object code for > > various cases, I am covered -- am I oversimpifying it? In > other words > > since valgrind operates on assembly instructions, it > shouldn't really > > matter what the original programming language was, right? > > Yes. > > > [...] > > concerned me since building a test framework based on an > potentially > > unstable framework is risky. So can you pls elaborate on potential > > breaking points with C++? > > I don't know, this stuff might be covered by the C++ ABI. I > do know that Valgrind intercepts things like 'operator new' > and I don't recall the mangling for that changing in a long time. > > Nick > ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
