On 12/18/2016 01:54 PM, Suchakra wrote: > I spent some time researching dynamic instrumentation for tracing a > few years back . We started with a ptrace based approach and developed > kaji (https://github.com/5kg/kaji) as a demo for inserting precompiled > lttng tracepoints. This was also tested with dyninst. Here are some > observations (http://www.dorsal.polymtl.ca/fr/system/files/11Dec2013.pdf). > Here is also some investigation on what happens underneath > (https://github.com/tuxology/lttng-ubench/blob/master/analysis/instr/dyninst_kaji). > > In addition, some other things to look out for would be : > 1. Fast Tracepoints in GDB that use a similar trampoline approach > 2. SystemTap's Stapdyn approach which uses dyninst > (https://research.cs.wisc.edu/htcondor/HTCondorWeek2013/paradyn-slides/stone-stapdyn.pdf) > 3. DynamoRIO (http://www.dynamorio.org/)
Thanks for the links, I'll check those out. > Also, some folks I know have complained about dynins't huge memory > consumption in a production simulation. I have not investigated that > myself, but I can if we are heading in this direction. Also, it may be > worthwhile to discuss if "spin-your-own" may be beneficial than an > available and tested framework. For example, Dyninst does recursive > trampoline checks and some other basic safety checks on snippets > before inserting them. It seems overkill in some places, but sometimes > it may add to robustness. Using an existing framework that's already thought of many of the pitfalls would definitely help. Dyninst keeps popping up in various discussions (esp in tracing circles) so will probably the first I'll further investigate. >>> Are the tracing folks discussing userspace upstream on the mailing lists >>> yet? If so, I'd like to participate :) >> >> sorry for delay and thanks a lot for all the links. >> starting next year we're planning to invest into building >> a prototype where we can inject the code into remote process, >> fixup usdt-s in the remote process to point to injected code >> and let this injected code interact with master process via >> shared memory. >> The goal is to build an alternative to uprobe+bpf at much higher speed. > > I am really interested in this now that academic life is getting over :) > Maybe we can try for a Dyninst based demo which can be quick to implement? > >>> libcompel - execute arbitrary code in a context of a foreign process >>> https://criu.org/Compel > > Wow this is cool. I did not know about this. Time to play with this! A few more links if you're interested: Katana: An ELF/DWARF Manipulation Tool with Hotpatching Capabilities http://katana.nongnu.org/doc/katana.html Living on the Edge: Rapid-Toggling Probes with Cross-Modification on x86 http://www.cs.indiana.edu/~rrnewton/papers/pldi16-crossmod.pdf -- Joe _______________________________________________ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
