Re: [DynInst_API:] Type conflict building parseAPI example

[Andrew Bernat <bernat@xxxxxxxxxxx>]

We're updating the ParseAPI docs, and I'd like to use this as the example - it's a lot more featured than the current one. Is that okay? We'll credit you, of course. 

Drew

On Feb 6, 2013, at 9:29 AM, E.Robbins <er209@xxxxxxxxxx> wrote:

Okay, I really should have checked this better before I sent it out!

I've added a last fix which is purely cosmetic - fixes the indentation in the final output, which was a bit messy in previous versions.

Sorry for 3 separate mails!

________________________________________
From: dyninst-api-bounces@xxxxxxxxxxx [dyninst-api-bounces@xxxxxxxxxxx] on behalf of E.Robbins [er209@xxxxxxxxxx]
Sent: 06 February 2013 15:15
Cc: dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] Type conflict building parseAPI example

Urr, one last tiny update - add start addresses as well as names to function nodes.

Ed
________________________________________
From: dyninst-api-bounces@xxxxxxxxxxx [dyninst-api-bounces@xxxxxxxxxxx] on behalf of E.Robbins [er209@xxxxxxxxxx]
Sent: 06 February 2013 15:09
To: Andrew Bernat
Cc: dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] Type conflict building parseAPI example

Ok, I have now also made the example a lot nicer - no dot errors and nodes are always printed in the right place. You can find it attached.

Cheers,
Ed
________________________________________
From: Andrew Bernat [bernat@xxxxxxxxxxx]
Sent: 05 February 2013 18:58
To: E.Robbins
Cc: dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] Type conflict building parseAPI example

On Feb 5, 2013, at 12:52 PM, E.Robbins <er209@xxxxxxxxxx<mailto:er209@xxxxxxxxxx>> wrote:

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<mailto: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><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><mailto:bernat@xxxxxxxxxxx>
http://www.cs.wisc.edu/~bernat





--
Andrew Bernat
Paradyn Project
bernat@xxxxxxxxxxx<mailto:bernat@xxxxxxxxxxx>
http://www.cs.wisc.edu/~bernat




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

--

Andrew Bernat

Paradyn Project

bernat@xxxxxxxxxxx

http://www.cs.wisc.edu/~bernat