Re: [DynInst_API:] the cause of uninstrumentable functions

[Victor van der Veen <vvdveen@xxxxxxxxx>]

> > 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