Re: [DynInst_API:] Unable to instrument chromium

[Bill Williams <bill@xxxxxxxxxxx>]

On 11/14/2014 05:29 AM, Adrian M Negreanu wrote:
> Hi,
>
> i'm trying to instrument the chromium binary and have a message printed
> before GLES2GetError called.
>
> I've used the example code from the DyninstAPI.pdf (attached) to which I
> added
>    bpatch.setTrampRecursive(true) and bpatch.setSaveFPR(false)
>
> The way I'm running it is :
>    DYNINSTAPI_RT_LIB=/usr/local/lib/libdyninstAPI_RT.so ./a.out
> path/to/chrome chrome
>
> I've compiled chromium so it contains debugging symbols and has around
> 1.3 GB.
> With instrumenation, the first log message from chrome shows up after 14
> minutes,
> and that's it. It doesn't continue
>
> Any tweaks I'm missing to make things faster ?
Two for correctness, and three for speed.

Correctness:
* saveFPRs is no longer a significant speed win, and disabling it can be 
a correctness loss when inserting calls to a wide variety of common libc 
functions--the XMM registers are used in all manner of unusual places.
* Inserting a call to printf where the argument totals don't match the 
format string is going to cause issues (possibly including an unbalanced 
stack and arbitrarily broken control flow).
Speed:
* Dyninst, like most programs that make heavy use of STL, performs 
remarkably badly at -O0. Make sure you've got an appropriately optimized 
(Release/RelWithDebInfo) build; if one of the distribution packages came 
prebuilt with debug binaries, please let us know which one(s).
* You're searching in the entire BPatch_image for GLES2GetError, which 
causes the executable and all of its dependent shared libraries to be 
searched for the function in question (and likely over-eagerly parsed). 
You can constrain this search by looking in the BPatch_module 
corresponding to the binary that you expect to find GLES2GetError in, 
which should significantly speed up the instrumentation process.
* While it's unlikely that the debug information that's present needs to 
be parsed to insert the instrumentation you want, it's possible that 
there's a bug causing that to happen.
If neither the correctness nor the speed fixes I suggest are helpful to 
you, if you can run your mutator under valgrind's massif tool and send 
me the results, I may have some insight into the problem.
> thanks
>
>
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx