[Soot-list] Soot-list Digest, Vol 106, Issue 16
hsadat
hsadat at gmail.com
Wed Feb 19 12:31:43 EST 2014
Hi Nate,
You're right, the PDG in Soot is based on the control flow dependencies;
however, as far as I know, any data flow dependence graph has not to be
based off of a control-flow one. In other words, data flow is going to be
just extra graph edges that carry the data information. The problem with
data flow is that it's application-specific so I'm not even sure if it
makes sense to have a generalized data flow dependence graph.
Hope that helps.
(Sorry for the late reply... I rarely check this email. Please reply to
shmohtasham at gmail.com if you need more help with PDG.)
--Hossein
On Sat, Feb 15, 2014 at 9:00 AM, <soot-list-request at sable.mcgill.ca> wrote:
> Send Soot-list mailing list submissions to
> soot-list at sable.mcgill.ca
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> or, via email, send a message with subject or body 'help' to
> soot-list-request at sable.mcgill.ca
>
> You can reach the person managing the list at
> soot-list-owner at sable.mcgill.ca
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Soot-list digest..."
>
>
> Today's Topics:
>
> 1. Re: Instrumenting exceptional edges in CFG (Nate Deisinger)
> 2. Working with PDGs in Soot (Nate Deisinger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 14 Feb 2014 15:25:25 -0600
> From: Nate Deisinger <ndeisinger at wisc.edu>
> Subject: Re: [Soot-list] Instrumenting exceptional edges in CFG
> To: "Bodden, Eric" <eric.bodden at sit.fraunhofer.de>
> Cc: Soot list <soot-list at sable.mcgill.ca>
> Message-ID: <52FE89C5.5020706 at wisc.edu>
> Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
>
> Hi Eric,
>
> I'm very sorry for the slow response on this.
>
> That 'nop' between label3 and label4 was indeed what was causing
> trouble. Since I had inserted it just as a way for me to offset my
> instrumentation code, there was no harm in removing the code that
> generated it (and indeed removing it is far more correct - my mistake!)
>
> Thanks for the response. Everything's up and running with regards to
> exceptions now.
>
> -Nate
>
> On 02/03/2014 11:22 AM, Bodden, Eric wrote:
> > Hi Nate.
> >
> >> Thanks for the tips. First off, I should clarify that I was well-aware
> the bad Jasmin meant I was generating bad Jimple somewhere - didn't mean to
> imply otherwise, or that this was Soot's fault. =)
> > Well, I guess Soot's error handling could be better, though...
> >
> >> I've tried transforming the code to match that invariant by generating
> new traps for instrumented edges that catch the exception, update our path
> counter, and then jump back to the original catch block, skipping over the
> exception identity statement there. Unfortunately, this method doesn't
> seem to work either, even in the degenerate case where only one block is
> trapped to begin with and we instrument that edge, meaning we can just
> adjust where the original trap points.
> >>
> >> To clarify, here's the relevant Jimple code generated right now for
> said degenerate case:
> >>
> >> // Initialization code goes here
> >> label0:
> >> nop;
> >> temp$0 = args;
> >> temp$1 = 0;
> >> temp$2 = temp$0[temp$1];
> >> temp$3 = staticinvoke <java.lang.Integer: int
> parseInt(java.lang.String)>(temp$2);
> >> goto label3;
> >>
> >> label1:
> >> nop;
> >> e := @caughtexception;
> >>
> >> label2:
> >> temp$4 = <java.lang.System: java.io.PrintStream out>;
> >> virtualinvoke temp$4.<java.io.PrintStream: void
> println(java.lang.String)>("ArrayIndexOutOfBoundsException!");
> >> nop;
> >> goto label3;
> >>
> >> label3:
> >> nop;
> >> virtualinvoke basicTry__PT_holder.<PathTrace: void close()>();
> >> return;
> >>
> >> nop;
> >>
> >> label4:
> >> e := @caughtexception;
> >> _____BL_temporary_long = basicTry__PT_holder.<PathTrace: long
> recentPath>;
> >> _____BL_temporary_long = _____BL_temporary_long + 1L;
> >> basicTry__PT_holder.<PathTrace: long recentPath> =
> _____BL_temporary_long;
> >> goto label2;
> >>
> >> catch java.lang.ArrayIndexOutOfBoundsException from label0 to
> label1 with label4;
> >> }
> >>
> >> Where originally label1 would have been the start of the catch block,
> and label4 is the new catch block generated for instrumentation purposes.
> I've observed two behaviors here:
> >> -If I leave the " e := @caughtexception;" in label1, Jasmin generation
> fails due to negative stack height at that statement. This is actually
> expected, as there are no traps treating that block as a catch block, so I
> assume Jasmin detects this case and correctly fails due to it being
> impossible for an exception to be on the stack at that point.
> >> -However, removing that statement still results in Jasmin generation
> failing, again due to negative stack height, at the " e :=
> @caughtexception;" of label4. (Or more precisely, store.r e).
> >>
> >> Any ideas on what might be causing this? It's almost like it doesn't
> think there's an exception on the stack at the handler.
> > I wonder whether the fall-through branch from label3 to label 4 might be
> the problem. Along this control flow you are popping an exception off the
> stack (at label 4) although no exception was at all thrown. This looks
> wrong to me. I think the basic block after label3 should end in a "goto
> <end of method>" or wherever it makes sense.
> >
> > Eric
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 14 Feb 2014 18:22:59 -0600
> From: Nate Deisinger <ndeisinger at wisc.edu>
> Subject: [Soot-list] Working with PDGs in Soot
> To: soot-list at sable.mcgill.ca
> Message-ID: <52FEB363.6010603 at wisc.edu>
> Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
>
> Hi folks,
>
> Sorry to keep coming back with more questions. As I mentioned in my
> last post I'm working on path tracing in Java programs, and the next
> step in my research is to start using the results to perform slicing on
> a program dependence graph (PDG) of the program.
>
> Of course, this implies having a PDG in the first place. I'm aware Soot
> has the HashMutablePDG class implemented, but that appears to be a
> control-flow only PDG (someone correct me if I'm wrong?)
>
> Does Soot have any built-in support for PDGs with data-flow edges as
> well, or does anyone know of a good PDG generator for Java programs that
> works with Soot? (I've found a thesis that discusses PDG and SDG
> generation in Soot, but it's several years old and the code does not
> appear to be available anymore - see
>
> http://www.slideshare.net/darvind/thesis-a-static-slicing-tool-for-sequential-java-programs
> ).
>
> Thanks very much,
> Nate
>
>
> ------------------------------
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>
> End of Soot-list Digest, Vol 106, Issue 16
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20140219/bab24952/attachment.html
More information about the Soot-list
mailing list