Re: [DynInst_API:] How to use DyninstAPI to get thread/process call stack in case of a signal delivery

[JiangJie <yangtzj@xxxxxxxxxxx>]

> > I do in fact know STAT, including its internals, a fair bit. And this
> > should be a fairly obvious extension if you take a look at the STAT
> > back-end code, as everything it's doing is with ProcControlAPI and
> > Stackwalker directly. You'd simply want to register your signal handler
> > callback with ProcControl, and have that callback trigger a stack walk
> > with the back end's Walker.
>
> There's a new release of STAT 2.1 that includes the initial version of DysectAPI support. With DysectAPI you should be able to configure STAT to do a stackwalk on a signal.
>
>
> And if you still want to roll your own, Bill suggested the correct approach. More specifically:
>
> 1. Use StackwalkerAPI to attach to a process. You'll get a Walker object
> 2. From a Walker, you can use getProcessState() to get a ProcDebug object.
> 3. A ProcDebug has a getProc() call that gets you a ProcControlAPI Process handle.
> 4. With ProcControlAPI you can register a callback that can trigger on a signal. From that callback, you can use the Walker to take a Stackwalk.
>
> You'd also need to modify the STAT source to coordinate a global stack walk upon a signal. Right now STAT expects to take a stackwalk from every process when triggered. It doesn't support taking a stackwalk from just a small subset of process that fault.
>
> -Matt
>

Hi Bill and Matthew,

Thanks for your helpful replies.

Today I took a look at STAT-2.1 source code and the DysectAPI.
And I will try it later.

Is there any document about DysectAPI?
Can STAT-2.1 collect and merge the call stacks from all processes upon a signal,
in the same way STAT FE handle call stacks on demand?
( Assume all processes get the same signal.)

Regards,
Jie