Re: [DynInst_API:] Logging the stack trace


Date: Mon, 23 Apr 2018 18:06:42 -0500
From: John Mellor-Crummey <johnmc@xxxxxxxx>
Subject: Re: [DynInst_API:] Logging the stack trace
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: johnmc@xxxxxxxx phone: 713-348-5179

On Apr 23, 2018, at 5:58 PM, Buddhika Chamith Kahawitage Don <budkahaw@xxxxxx> 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 <johnmc@xxxxxxxx> 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: johnmc@xxxxxxxx phone: 713-348-5179

On Apr 23, 2018, at 4:55 PM, Buddhika Chamith Kahawitage Don <budkahaw@xxxxxx> 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 <budkahaw@xxxxxx> 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 <mxz297@xxxxxxxxx> 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 <cbudchan@xxxxxxxxx> 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 <mxz297@xxxxxxxxx> 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). 

Thanks,

--Xiaozhu

On Sun, Apr 22, 2018 at 2:49 PM, budchan chao <cbudchan@xxxxxxxxx> 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
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/ mailman/listinfo/dyninst-api



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


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



[← Prev in Thread] Current Thread [Next in Thread→]