One more heretical suggestion for the Dyninst mailing list: you might be interested in the paper and download of software developed by some of my students for use with Pin.
Milind Chabbi, Xu Liu, and John Mellor-Crummey. 2014. Call Paths for Pin Tools. In Proceedings of Annual IEEE/ACM International Symposium on Code Generation and Optimization (CGO '14). ACM, New York, NY, USA, , Pages 76 , 11 pages. DOI=http://dx.doi.org/10.1145/2544137.2544164 -- John Mellor-Crummey Professor Dept of Computer Science Rice University email: [email protected] phone: 713-348-5179 > On Apr 23, 2018, at 5:58 PM, Buddhika Chamith Kahawitage Don > <[email protected]> wrote: > > Hi John, > > Looks like it's sampling based. For my current requirement I want full trace > of the running stack at each call chain. Thanks for the suggestion though :). > I've heard of it before. Looks like a pretty useful project. > > On Mon, Apr 23, 2018 at 6:19 PM, John Mellor-Crummey <[email protected] > <mailto:[email protected]>> wrote: > Buddhika, > > Rather than using dyninst to collect every unique calling context that arises > while executing a program using unwinding, you might find it appropriate to > use HPCToolkit (http://hpctoolkit.org <http://hpctoolkit.org/>), which can > measure your executing program using sampling + call stack unwinding, show > you all of the calling contexts that sampling reveals, and annotate each > calling context with metrics (e.g., instructions executed, or cycles). If > that doesn’t meet your needs, return to your discussion in progress :-). > -- > John Mellor-Crummey Professor > Dept of Computer Science Rice University > email: [email protected] <mailto:[email protected]> phone: > 713-348-5179 > >> On Apr 23, 2018, at 4:55 PM, Buddhika Chamith Kahawitage Don >> <[email protected] <mailto:[email protected]>> wrote: >> >> Sorry for mixing up the emails. Earlier one was from my private email. >> >> On Mon, Apr 23, 2018 at 5:49 PM, Buddhika Chamith Kahawitage Don >> <[email protected] <mailto:[email protected]>> wrote: >> I want to collect all the stack traces. This is for a study of spec >> applications. >> >> On Mon, Apr 23, 2018 at 5:40 PM, Xiaozhu Meng <[email protected] >> <mailto:[email protected]>> wrote: >> Do you want to collect all stack traces during its run or you have a few >> points you are interested in where you want to collect stack traces (such as >> function entries, basic block entries)? >> >> On Mon, Apr 23, 2018 at 4:20 PM, budchan chao <[email protected] >> <mailto:[email protected]>> wrote: >> Right, I want to just collect all the return addresses and get all the stack >> traces a program makes during its run. So would work if I add this stack >> walking code as part of return instrumentation? >> >> On Monday, 23 April, 2018, 4:50:44 PM GMT-4, Xiaozhu Meng <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> Hi, >> >> Passing (rsp) to your instrumentation function is not going to do what you >> plan to do because Dyninst's internal instrumentation code will have changed >> the value of rsp. >> >> For us to better help you, can you describe what exactly you would like to >> do? It seems to me that you are trying to collecting return addresses and >> manually reconstruct call stacks. If it is the case, the stackwalkAPI is >> better suited for this purpose. You can refer the documentation for better >> idea of what stackwalkAPI can do >> (https://github.com/mxz297/dyninst/blob/master/stackwalk/doc/stackwalk.pdf >> <https://github.com/mxz297/dyninst/blob/master/stackwalk/doc/stackwalk.pdf>). >> >> >> Thanks, >> >> --Xiaozhu >> >> On Sun, Apr 22, 2018 at 2:49 PM, budchan chao <[email protected] >> <mailto:[email protected]>> wrote: >> I want to use Dyninst to trace the runtime stack. I was thinking doing a >> call out to an instrumentation function at each function entry which would >> accept the dereferenced rsp value (which will be the return address at the >> function entry) as an argument and log it within this instrumentation >> function which I load from a shared library. I am not quite sure how to get >> the dereferenced register value and do the function call using it as an >> argument. I see Bpatch_registerExpr but I am not sure how to initialize with >> the dereferenced rsp register value. Can somebody give me a pointer on how >> to do this? Or is there a better of doing it? >> >> Thanks >> >> >> ______________________________ _________________ >> Dyninst-api mailing list >> [email protected] <mailto:[email protected]> >> https://lists.cs.wisc.edu/ mailman/listinfo/dyninst-api >> <https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api> >> >> >> >> _______________________________________________ >> Dyninst-api mailing list >> [email protected] <mailto:[email protected]> >> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >> <https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api> >> >> >> _______________________________________________ >> Dyninst-api mailing list >> [email protected] <mailto:[email protected]> >> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >> <https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api> >
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
