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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *John Mellor-Crummey <joh...@rice.edu>
> *Sent: *Thursday, May 31, 2018 9:58 PM
> *To: *Xiaozhu Meng <mxz...@gmail.com>
> *Cc: *John Mellor-Crummey <joh...@rice.edu>; Keren Zhou <k...@rice.edu>
> *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: joh...@rice.edu <joh...@rice.edu> phone:
> 713-348-5179
>
>
>
> On May 31, 2018, at 8:55 AM, Xiaozhu Meng <mxz...@gmail.com> 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 <joh...@rice.edu>
> 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: joh...@rice.edu <joh...@rice.edu> phone: 713-348-5179
>
>
>
>
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@cs.wisc.edu
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>
>
>
>
>
>
>
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
