Thanks for the response!
I will follow your instructions and let you know if I have further questions.
Sent from Mail for Windows 10
From: Xiaozhu Meng
Sent: Thursday, June 14, 2018 3:40 AM
To: Keren Zhou
Cc: dyninst-api; John Mellor-Crummey; Mark W. Krentel
Subject: Re: [DynInst_API:] Creating ParseAPI graphs to CFGs
forexternalrepresentations; adding line map information from external sources
Hi Keren,
I am sorry for the late response. See my inlined comments.
//ret_func->_cache_valid = true;
In your case, I don't think you need to maintain _cache_valid, because
_cache_valid is used by the Dyninst parser. You should be able to ignore it.
//ret_func->add_block(ret_block);
Right now, there is indeed no easy way to add a block to a function, because
Function::add_block is declared as a private member function. Personally, I am
fine with changing Function::add_block to a public function. Making it public
is consistent with an existing interface Edge::install(), which adds an edge to
the source and target block.
//ret_func->_call_edge_list.insert(ret_edge);
There is no good interface for inserting call edges to a function. But I don't
think this information is needed for loop analysis because the loop analysis in
ParseAPI just iterate every edge of a basic block and ignore the call edges. If
you want to maintain a list of call edges in a function, you can either create
a new public interface in parseAPI/h/CFG.h to access _call_edge_list, or you
can inherit the ParseAPI::Function class and maintain your own version of call
edge list.
Considering that you may want to maintain other information about a function, I
would recommend inherit the ParseAPI::Function.
} else { // TODO(Keren): Add more edge types
ret_edge = new Edge(ret_block, ret_target_block, DIRECT);
}
ret_edge->install();
edges_.add(*ret_edge);
}
}
return ret_func;
}
}
return NULL;
// iterate blocks
// add blocks
// iterate targets
// add edges
}
Regards,
Keren
Sent from Mail for Windows 10
From: John Mellor-Crummey
Sent: Thursday, May 31, 2018 9:58 PM
To: Xiaozhu Meng
Cc: John Mellor-Crummey; Keren Zhou
Subject: Re: [DynInst_API:] Creating ParseAPI graphs to CFGs for
externalrepresentations; adding line map information from external sources
Xiaozhu,
Thanks! We’ll give the CFG construction a try.
I believe that Bill thought that I could push in line maps, but I haven’t tried
it yet.
--
John Mellor-Crummey Professor
Dept of Computer Science Rice University
email: [email protected] phone: 713-348-5179
On May 31, 2018, at 8:55 AM, Xiaozhu Meng <[email protected]> wrote:
Hi John,
I can answer the part about ParseAPI. You can definitely use the CFGFactory to
construct your ParseAPI CFG, which should contains a bunch of
ParseAPI::Function, ParseAPI::Block, and ParseAPI::Edge objects. Then, you can
invoke loop analysis through Function objects. You won't have the
SymtabCodeSource or CodeObject, but they are not needed for loop analysis.
Thanks,
--Xiaozhu
On Tue, May 29, 2018 at 2:53 PM, John Mellor-Crummey <[email protected]> wrote:
We are interested in building ParseAPI CFGs for a GPU binary given a
representation of the CFG for a GPU binary in as a graph in dot format. We are
currently parsing the GPU CFG for each function out of dot, understand its
blocks, edges, and calls. From scanning through the documentation in ParseAPI,
it is not clear whether it would be feasible to simply use the CFG factory
interface to supply graph elements to Dyninst to construct a CFG. If we did so,
would it then be possible to use the Loop Analyzer to analyze this CFG? (At
present, we have a copy of the LoopAnalyzer code that analyzes our lightweight
internal representation of the dot graph, but it would be better for
HPCToolkit’s hpcstruct to just work with one representation - Dyninst CFGs for
binaries.)
Also, can I push line map information into dyninst from the outside? Line maps
for optimized GPU binaries can’t be read from libdw. If I write my own reader,
can I push information associating address ranges with source file and line?
There is no information about compilation units, which is what makes NVIDIA’s
cubin line maps unreadable with libdw. If I were to push information in from
the outside about source lines and files, would I have to fake a compilation
unit, or could I just put it in the default module?
We would appreciate any advice. If is easier to have a conversation than
sending a long email, let me know.
--
John Mellor-Crummey Professor
Dept of Computer Science Rice University
email: [email protected] phone: 713-348-5179
_______________________________________________
Dyninst-api mailing list
[email protected]
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
[email protected]
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
