Re: [DynInst_API:] the cause of uninstrumentable functions

[Xiaozhu Meng <mxz297@xxxxxxxxx>]

Hi Victor,

I am working on the project of improving our abilities to resolve jump tables. My code is able to resolve the jump tables in strncmp, memcmp, and strcmp.Â

I don't find a function "__cfree" in my local version of libc. But I do find a "libc_free", which contains a unresolved indirect branch and the unresolved indirect branch looks like an indirect tail call.Â

My code is currently under integration and should be included in the next release of Dyninst.

Thanks

--Xiaozhu

On Thu, Feb 12, 2015 at 3:15 PM, Bill Williams <bill@xxxxxxxxxxx> wrote:

On 02/12/2015 12:05 PM, Victor van der Veen wrote:

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

Appears not to be in at least the strcmp_sse3 case, for what that's worth; I've had a little bit of time to investigate this. There's just an indirect branch that we don't presently resolve.

Better resolution of these branches is an ongoing research topic in the group; I'll confirm whether the improvements we're working on deal with these functions.

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?

Well, it's important to be able to instrument everything that users care about, provided that a) it's possible at all and b) it provides the results they expect/want. I don't think there's anything tricky about str(n)cmp/memcmp/free that would make them not worth worrying about.

There will always be some percentage of functions that we mark uninstrumentable until/unless we change some of our fundamental abstractions/assumptions (e.g. PLT stubs, which are always functions and always uninstrumentable). But ultimately we do want to be able to instrument all "real" functions safely.

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

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api