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]> 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), 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] <[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]> 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]> 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]> >>> 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]> 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/dyn >>>> inst/blob/master/stackwalk/doc/stackwalk.pdf). >>>> >>>> Thanks, >>>> >>>> --Xiaozhu >>>> >>>> On Sun, Apr 22, 2018 at 2:49 PM, budchan chao <[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] >>>> 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 > > >
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
