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), 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] phone: 713-348-5179
> On Apr 23, 2018, at 4:55 PM, Buddhika Chamith Kahawitage Don > <[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] > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
