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

[JiangJie <yangtzj@xxxxxxxxxxx>]

Hi all,

I'm a researcher from P.R.China and very interested in DyninstAPI.
Currently I am considering  using DyninstAPI to get thread/process call stack
in case a specific signal ( like SIGSEGV ) is delivered to a thread/process on X86/Linux platform.

 

Following is my initial idea.

Firstly, I need to attach the target mutatee process using Bpatch::processAttach(),

then continue the attached process with BPatch_process::continueProcess(),

and after that, make the mutator process wait for a status change in the mutatee process by calling Bpatch::waitForStatusChange().

As specified by PTRACE syscall,  if a thread/process is in attached state, a signal delivery normally will cause the thread/process into a "signal-delivery-stop" state. So I expect that  Bpatch::waitForStatusChange() will catch such stop. Upon detecting such  "signal-delivery-stop" , we can call Bpatch_thread::getCallStack() to collect the context where a signal is triggered.

However,  in my test program, waitForStatusChange()  API does not  detect such state change.

After enabling the debug output of DynisntAPI, I found that  the delivered signal

( in my test program, it's SIGSEGV ) and the signal-delivery-stop is indeed detected
and handled by DyninstAPI in some signal handler and callbacks.
 And after that ,the same signal is re-injected to the target process and the target process continues.

So my question is, how to collect the target process's call stack in case of a signal delivery by using DynisntAPI?
A solution comes to me is to register a signal handler callback by invoking registerSignalHandlerCallback.
Is this a correct solution? Or is there any other better solution in DyninstAPI?

Jie