Re: [DynInst_API:] the cause of uninstrumentable functions

[Victor van der Veen <vvdveen@xxxxxxxxx>]

Hi Xiaozhu, Bill,

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

This sounds very promising. Any chance that you can share a recent patch
so I can give this a try locally?

>         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 will have to take a closer look, but wouldn't it be possible to
implement a 'force instrument' option? In my current project, I am
inserting snippets on BPatch_entry points only, using BPatch_callBefore.
I would guess that for these instrumentations, it is not necessary for
Dyninst to know the complete CFG of the target function. It should just
know where the first basic block ends.
One could of course think of a few cases where this can still go wrong,
so I don't think that we should expect such option to appear in a future
release, right? :)

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

I'm looking forward for the next release! Is there an ETA yet?

Cheers,
Victor

Attachment: signature.asc
Description: This is a digitally signed message part