Re: [DynInst_API:] Slicing across blocks

[Mohamed Elsabagh <melsabag@xxxxxxx>]

Thanks Matt and Bill. Looking forward for the next release. Dyninst has greatly evolved over the past few years.. Good going!

On Tue, Apr 26, 2016 at 4:56 PM Matt Morehouse <mm@xxxxxxxxxxx> wrote:

Hi Mohamed,

After discussing with Bill and pulling up the ABI reference, we have confirmed that %ebx is callee-save, even when used in PIC as the GOT base register. Thus, %ebx should be in callRead_ but not callWritten_, and moving line 186 to after 191 is the correct fix.

- Matt

---

From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of Mohamed Elsabagh <melsabag@xxxxxxx>
Sent: Tuesday, April 26, 2016 3:09:51 PM
To: Bill Williams; dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] Slicing across blocks

Â

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

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