Re: [DynInst_API:] Creating ParseAPI graphs to CFGs for externalrepresentations; adding line map information from external sources

[Xiaozhu Meng]

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-CrummeyProfessor
> Dept of Computer Science  Rice University
> email: joh...@rice.edu  phone:
> 713-348-5179
>
>
>
> On May 31, 2018, at 8:55 AM, Xiaozhu Meng  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 
> 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  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

Re: [DynInst_API:] libdwarf usage in Dyninst?

[Sasha Da Rocha Pinheiro]

Yes, that is true.

Get Outlook for Android


From: Dyninst-api  on behalf of Jim Galarowicz 

Sent: Wednesday, June 13, 2018 11:21:30 AM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] libdwarf usage in Dyninst?

Hi all,

I'm trying to get a spack file change to the dyninst/package.py file
through the spack review process.

My changes say that versions 9.3.2 and below use libdwarf and future
versions use libdw.

Is that true?

Thanks,

Jim G

___
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

[DynInst_API:] libdwarf usage in Dyninst?

[Jim Galarowicz]

Hi all,

I'm trying to get a spack file change to the dyninst/package.py file 
through the spack review process.


My changes say that versions 9.3.2 and below use libdwarf and future 
versions use libdw.


Is that true?

Thanks,

Jim G

___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] OPENMP Support with Dyninst

[Xiaozhu Meng]

Hi Jordi,

I am sorry for the late response. Based on my 7-year experience working in
the Dyninst group, I am not aware of any thread of work following up the
OpenMP Support document. My best guess is that it was a research project,
but never made into the mainstream Dyninst.

Thanks,

--Xiaozhu

On Fri, Jun 8, 2018 at 1:32 PM Jordi Alcaraz Rodriguez <
jordi.alca...@uab.cat> wrote:

> Hello,
>
>
> I'm interested in OpenMP Support with dyninst and found in Paradyn/Condor
> Week 2007 a document called "Supporting openMP and other Higher Languages
> in Dyninst".
>
>
> In this document OpenMP is shown for Solaris and Power, is there support
> for other processors?
>
>
> Where could I consult functions and types for OpenMP like BPath_parRegion,
> getParRegions and others? I looked at the documentation but didn't find it.
>
>
>
> Best regards,
> Jordi Alcaraz
>
> ___
> 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