Re: [DynInst_API:] Slicing across blocks

[Bill Williams <bill@xxxxxxxxxxx>]

On 04/26/2016 03:09 PM, Mohamed Elsabagh wrote:

Thanks for the reply, Bill!Â

I am aware that the slicer is inter-procedural. I have actually tried overriding followCall in the predicates, but followCall wasn't even called by the slicer. As far as I could debug, the last predicate the slicer called was followReturn, which killed ebx and, therefore, the slicer stopped (no new candidate regions were added to slice on).

followReturn is a method in the slicer but not in the predicates, at least in the code I have from latest master. I also don't see a way to avoid hitting the followCall predicate if followReturn gets invoked (unless you're using default predicates and the compiler optimizes out the whole aggregation loop). And I don't immediately see the call chain that lets followReturn kill anything.

You're using the latest official release, right? I can sanity-check against that tag, but I'd really like to see the chain of events here (call stack etc)...something is exceptionally hinky.

Mohamed

On Tue, Apr 26, 2016 at 3:28 PM Bill Williams <bill@xxxxxxxxxxx> wrote:

On 04/24/2016 09:29 PM, Mohamed Elsabagh wrote:

So I enabled debug mode for the slicer, and it seems that the slicer kills the assignment to ebx at call foo(). I can see that ebx is (implicitly) added to the call-written list here:Â

dataflowAPI/src/ABI.C:

185: Â // PLT entries use ebx

186: Â callRead_[machRegIndex_x86()[x86::ebx]] = true;

187:

188: Â // TODO: Fix this for platform-specific calling conventions

189:

189: Â // Assume calls write flags

191: Â callWritten_ = callRead_;

Moving line 186 after the assignment to callWritten (line 191) seems to solve the issue for me.

Thoughts?Â

Two thoughts (and I apologize for the delay on this):

One, I'm pretty sure that your proposed fix is either incomplete or unsafe. It might work; ebx is that strange beast that's a callee-saved maybe-parameter, so we might be able to treat it as read-not-written, but I'd need to do a bit more reading and thinking on this.
Two, our slicer will let you perform interprocedural slicing (or even conditionally interprocedural!) by using custom slicing predicates. I must also apologize for the lack of documentation in dataflowAPI; we're finally going to fix that for 9.2's official release. Short version: if you override followCall to do something sensible (say, follow calls to depth 1), you should be able to get a neatly resolved slice (and it will account for anything that foo does/doesn't do to ebx, as well).

--bw

On Sun, Apr 24, 2016 at 4:43 PM, Mohamed Elsabagh <melsabag@xxxxxxx> wrote:

I am trying to slice on the last call in the snippet below, using the default predicate, but the returned slice only contains a single node (the call instruction itself):

mov 0x804ba3, %ebx
add 0x5, %ebx
call foo()
mov %eax, 0x1c(%esp)
call *%ebx // backward slice from here

The same exact slicing code is working fine on all other indirect calls in the binary. This particular call differs from the rest in that the dereferenced register (ebx) is in a different basic block than the call instruction. Are there any flags that I need to pass to the slicer to resolve this? Â

I am invoking the slicer as follows:Â

AssignmentConverter ac(true, false);

vector<Assignment::Ptr> assigns;

ac.convert(insn, insn_addr, func, block, assigns);

Slicer slicer(assigns.back(), block, func);

Slicer::Predicates defaultPredicates;

GraphPtr graph = slicer.backwardSlice(defaultPredicates);

Thanks,

Mohamed

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

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