Re: [DynInst_API:] the cause of uninstrumentable functions

[Bill Williams <bill@xxxxxxxxxxx>]

On 02/12/2015 11:14 AM, Victor van der Veen wrote:
> Hi,
>
> 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.
> 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 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.
> Cheers,
> Victor
>
>
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx