> > I'm using the DyninstAPI to instrument a number of libc functions on my > > x86-64 machine. This is working successfully most of the time, but some > > functions are unfortunately rendered not-instrumentable by Dyninst > > (isInstrumentable() returns false). I also noticed that calling > > BPatch_function->findPoint(BPatch_exit) for these functions does not > > return much either. I now assume that Dyninst is having problems > > generating a CFG for these functions. > > > Yes, generally uninstrumentable means we believe that a function has > unresolved indirect control flow. This may be because there's a jump > table/indirect tail call/whatever that we're not resolving that's > properly part of the function, or it may be because we've incorrectly > decided that the function shares code with something else that has > unresolvable indirect control flow.
It could be the latter actually... > > I'm wondering if anyone has seen similar issues and can perhaps explain > > why this is happening. Does Dyninst indeed have problems rendering a > > CFG? Example libc functions that are causing issues are: > > > > free (__cfree) > > strncmp (__GI___strncmp_ssse3) > > memcmp (__memcmp_sse4_1) > > strcmp (__strcmp_ssse3) > > > > As you can see these are mostly optimized implementations. When looking > > at the disassembly of libc (using objdump), I wonder if Dyninst has > > perhaps problems interpreting certain nop code? For example: > > > > 83a75: 66 66 2e 0f 1f 84 00 data32 nopw %cs:0x0(%rax,%rax,1) > > 83a7c: 00 00 00 00 > > > > Could it be the case that Dyninst is interpreting this as data which > > then cause a faulty CFG to be generated? > > > Pretty sure it's not the nops being interpreted as data, though I could > have sworn that a double-66 prefix is illegal... I'll have a look. > > I will have a more detailed look later to see if there are other ways > > for me to still instrument these functions, but I figured that someone > > here perhaps has an answer already. > > > > I'm running Ubuntu 14.04 and Dyninst 8.1.2. > > > If memory serves, quite a few of these should be fixed in Dyninst 8.2. > There were some bugs that interfered with our ability to cleanly parse > quite a few optimized libc constructs in 8.1.2, both in the > false-sharing category and in the failure-to-resolve category. > > There may still be some uninstrumentable functions in libc in Dyninst > 8.2 but there should be considerably fewer of them. Let us know if you > find important ones. Ah sorry, that was a typo. I'm at Dyninst 8.2.1 - not 8.1.2. So I guess the above are quite important? Cheers, Victor _______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
