Re: [DynInst_API:] Binary Rewriting using wrapFunction

[Bill Williams <bill@xxxxxxxxxxx>]

> > ELF symbol tables don't lock in which library it comes from, which is
> > why I hedged about loading order above.  If your wrapper function is
> > named the same as the original symbol, then you'll only win if your
> > library is loaded first.  If you give your functions unique names, then
> > I'd think (hope) it should work.  :)
> This makes sense :) This is exactly, what I have been trying within my
> program: The resulted binary, however results with wrapped functions
> calls to either functions that are part of the binary itself or to
> statically linked functions (whereas I haven't tried to wrap statically
> linked library function calls, yet -- these should behave like the
> remaining functions located within the binary). Unique symbols of the
> wrappers to dynamically linked functions unfortunately do not even
> appear within the symbol table after rewriting.
>
> My guidelines are as follows:
> * printf() // library function to be wrapped
> * bg_prinf() // wrapper function
> * orig_printf() // represents the original printf() after wrapping
>
> But maybe, I have not thought about some details within my
> implementation. Here is a short snippet from my code concerning the
> function wrapping:
>
> ---
> ...
> /* function names in question: providing unique names */
> string newFuncName = "bp_" + oldFuncName;
> string origFuncName = "orig_" + oldFuncName;
>
> /* find functions in question */
> img->findFunction(oldFuncName.c_str(), funcs);
> BPatch_function *oldFunc = funcs[0];
>
> img->findFunction(newFuncName.c_str(), funcs);
> BPatch_function *newFunc = funcs[0];
>
> /* find the symbol, the orig func shall be referred to from now on */
> Module *mod = SymtabAPI::convert(newFunc->getModule());
> for (auto s=symbols.begin(); s!=symbols.end(); s++) {
> 	if (!(*s)->getPrettyName().compare(origFuncName))
> 		bp_as->wrapFunction(oldFunc, newFunc, (*s));
> }
>
> ---
>
> PS: In contrast to the solution provided by the Dyninst documentation
> (which utilizes the function "findSymbol(...)" to get the symbol of the
> function, which should represent the original library function from now
> on), I am using the for loop to get the right symbol, since the
> documented solution did not work (I am using Dyninst 8.2.1).
Going through the entire pile of functions by pretty name seems 
suboptimal, even if we've somehow misfiled things into the wrong 
module(s). What's going wrong with the manual example? No symbol comes 
back, or we find a non-useful one?
> Best regards,
> Sergej
>
>
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx