On 04/21/2014 10:26 AM, JiangJie wrote: > > > > Date: Mon, 21 Apr 2014 09:59:44 -0500 > > From: b...@cs.wisc.edu > > To: yang...@hotmail.com > > CC: dyninst-api@cs.wisc.edu > > Subject: Re: [DynInst_API:] How to use DyninstAPI to get > thread/process call stack in case of a signal delivery > > > > On 04/20/2014 09:02 AM, JiangJie wrote: > > > Hi Ray, > > > > > > Yes it's possible to use ProcControlAPI directly to just intercept > signal. > > > > > > But my purpose is to collect the thread/process's callstack in case of > > > a signal delivery, > > > in order to know the context where the signal is raised. > > > So I would like to call some API like BPatch_thread::getCallStack() > > > in the registered event callback for ProcControl > > > > > > My question is, if I use > > > ProcControlAPI->Process::registerEventCallback(EventType::Signal, > > > my_signal_cb) > > > to register a callback to intercept a signal, how to get the callstack > > > in the registered callback? > > > Is it possible to make use of BPatch_thread::getCallStack() in the > > > registered signal callback? > > > Or is there any other solution? > > > > > > Regards, > > > Jie > > > > > Jie-- > > > > I'm assuming that you just want a debugging call stack, and aren't > > aiming for any sort of recovery. > > > > If you set DYNINST_DEBUG_CRASH in your environment, that should produce > > a stack trace and register contents. You can set that variable to the > > location of your preferred gdb, which will attempt to attach gdb to the > > mutatee, or set it to "sleep", which will leave the mutator spinning in > > a sleep loop. Any other value should produce a core file (if your > > environment is set up to allow them). > > > > Hope that helps. > > > > --bw > > > > Bill, > > Do you know STAT? > One main functionality of STAT is to collect call stacks from target > processes on demand, > on the base of DyninstAPI or StackWalkerAPI. > But STAT only supports on-demand collecting of call stacks. > Actually what I am planning to do is to extend STAT to support > event-based collection of call stacks, > e.g, to collect call stacks in case of SIGSEGV. Since I still want to > reuse STAT's infrastructure > ( especially for parallel jobs ), I would prefer to collect the target > mutatee's call stacks in the context of STAT Backend process and then > send it back to STAT front end. > > I haven't tried your solution yet and have no idea if it works for my > purpose. > But I think a signal handler callback is more intuitive for me. > Jie--
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. If Dyninst is involved in any extension of STAT, something is likely very wrong with the design; the current version of STAT solely depends on Dyninst subcomponents, and adding Dyninst itself would break the existing STAT process control model. > Jie > > > > -- --bw Bill Williams Paradyn Project b...@cs.wisc.edu _______________________________________________ Dyninst-api mailing list Dyninst-api@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api