I do have valgrind - I'll check it out tomorrow. Did you want me to do some particular check (I mostly use it for leak checking)?
The default run will identify memory errors. I'd like to know what we're double-deleting, since it seems to vary by platform. Odd.
I find it a bit strange that when the control flow recovery runs into a call it creates an edge to the called function *and* one to the following block (the one starting immediately after the call site). Shouldn't it make an edge going to the call and then an edge from the return block of the called function to the following block? Otherwise you are assuming that the function will return. I am sure there is a good reason for this (probably because you can't always find the return of a function?) but I just wondered what the reasoning was?
It's to make intra-function analysis easier. We create a virtual edge with a type of CALL_FT to link the call to where execution will return. We check for non-returning functions and omit CALL_FT if we find them, though that analysis turns out to be remarkably difficult.
Basically, it's to make life easy for people that don't want full interprocedural analysis.
Drew
Cheers,
Ed
________________________________________
From: Andrew Bernat [bernat@xxxxxxxxxxx]
Sent: 05 February 2013 18:01
Subject: Re: [DynInst_API:] Type conflict building parseAPI example
Thanks, this is very nice.
WRT the crash - do you have valgrind on your system? If so, could you run it and send me the output? I'd be interested to know why delete isn't working. Not that I'm at all surprised - memory management is a pain.
Drew
On Feb 5, 2013, at 8:14 AM, E.Robbins <er209@xxxxxxxxxx<mailto:er209@xxxxxxxxxx>> wrote:
Hi again,
I added a couple of lines to your example and now it groups nodes from the same function into clusters and labels function nodes with the name of the function... makes it a bit clearer what is going on. Give it a try! I've attached it.
BTW, I commented out the deletes at the end because one of them causes a crash, at least on my system.
Cheers,
Ed
--
Andrew Bernat
Paradyn Project
bernat@xxxxxxxxxxx<mailto:bernat@xxxxxxxxxxx>
http://www.cs.wisc.edu/~bernat
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}