Re: [DynInst_API:] Stackwalking in a mutatee

[Matthew LeGendre <legendre1@xxxxxxxx>]

Marc,

You essentially needs a function that translates code addresses in the 
Dyninst heap to original code addresses.  For every Dyninst heap address 
you get out of your stackwalk you need to translate it back to the 
original address before continuing the stackwalk.
The Dyninst mutator has the data structures needed to do this, but it 
doesn't output them.  You may be able to modify Dyninst to output this 
information.
The mutator-based Stackwalker does this already.  See the 
StackwalkInsturmentationHelper::isInstrumentation(...) function in 
http://git.dyninst.org/?p=dyninst.git;a=blob;f=dyninstAPI/src/stackwalk-x86.C
-Matt


On Wed, 28 Aug 2013, Marc Brünink wrote:
> Thanks for your fast reply!
>
> I tried to use setInstrStackFrames before and it did not work. I just 
> tried again to make sure I did not do a stupid mistake. Still does not 
> work.
> I can get a backtrace of the instrumentation. I succeed in getting a 
> nice backtrace of all instrumentation functions. However, I fail to get 
> a backtrace of the actual application. It stops somewhere in 
> DYNINSTstaticHeap. I get something like
> 	my_super_instrumentation_function_1
> 	my_super_instrumentation_function_2
> 	DYNINSTstaticHeap_16M_anyHeap_...
>
> I understand why this happens. However, I am still searching for a nice 
> and clean solution.
> I will continue to try a couple of things. Especially, I want to try to 
> walk the stack starting at the frame which was active before I called 
> any of the instrumentation functions. This would be good enough. Not 
> sure whether it will work though.
> In the meantime I am more than grateful for any other ideas.
>
>
> Marc
>
>
> On Aug 29, 2013, at 1:00 AM, Matthew LeGendre wrote:
>
> > It's been several years since I tried doing 1st-party stackwalks from an
> > instrumented mutatee and things may have changed.  But the last time I did
> > this you could add a call to
> >
> >   BPatch::setInstrStackFrames(true);
> >
> > before you insert instrumentation.  This would cause Dyninst to generate
> > stack frames around generated instrumentation.  That adds runtime
> > overhead, but also gives a stack walker sufficient information to walk out
> > of the instrumentation.
> >
> >
> > I believe there's also efforts underway to have Dyninst start updating
> > existing DWARF stack unwinding information as it instruments and relocates
> > code.  But I'm not sure where those efforts stand or when they'd appear in
> > a released Dyninst.  Someone from the Dyninst team would have to comment.
> >
> > -Matt
> >
> > On Wed, 28 Aug 2013, Marc Brünink wrote:
> > > Dear all,
> > >
> > > short version:
> > > What is the appropriate way to walk the stack in a mutatee?
> > >
> > > long version:
> > > StackwalkerAPI implements basic stack walking. Some code in Dyninst
> > > implements the additional tweaks necessary to handle the complexity added by
> > > instrumentation. Thus, we can still perform a third party stackwalk of
> > > instrumented code.
> > >
> > > But how do I perform a first party stackwalk in the mutatee? The problem is
> > > that only the mutator knows about all this additional Dyninst features, e.g.
> > > which code got relocated, etc.
> > >
> > > I suppose this is a very common problem. However, at the moment I fail to
> > > find a nice, clean, and easy way to walk the stack in the mutatee.
> > > Before I dive into this in more detail, let me ask a simple question:
> > >
> > > Is there an obvious way to walk the stack in the mutatee which I just don't
> > > know about? Or do I have to manually make sure the FrameSteppers etc. in my
> > > mutatee are up-to-date?
> > >
> > > Marc
> > > _______________________________________________
> > > Dyninst-api mailing list
> > > Dyninst-api@xxxxxxxxxxx
> > > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api