Re: [DynInst_API:] StackMod

[Marc Brünink <marc@xxxxxxxxx>]

I just had my first look at StackMod.

A stack manipulation that inserts stack space is naturally always paired 
with a stack manipulation that removes stack space.
When I insert code at the entry and exit points of functions, the code 
at the exit points might be called before the code at the entry points.
I suppose the same can happen with the paired insert/remove stack 
modifications? Obviously, it would not be good to remove a stack 
insertion (aka reset the stack pointer) if the stack insertion never 
actually happened.
That would be a reason why StackMod only supports rewriting and not 
dynamic instrumentation.
Does that make sense?

Marc


On 13/01/2016 19:33, Marc Brünink wrote:
> Hi Matt (and everybody else),
>
> that is quite interesting indeed. Unfortunately I really need dynamic
> instrumentation.
>
> Actually, at the moment, I would be quite happy already if I could
> simply allocate something on the stack. I searched the DyninstAPI but
> failed to find an appropriate interface.
>
> Is there any support to simply allocate a variable on the stack?
>
> Marc
>
>
> On 09/01/2016 07:20, Matt Morehouse wrote:
> > Hi Marc,
> >
> > Yes, StackMod is only implemented for x86 and x86-64 in rewrite mode.
> > I'm not sure why only rewrite mode is supported, perhaps someone else
> > could comment?
> >
> > But the major challenge we're facing is that it is often difficult to
> > obtain a complete-enough understanding of how the stack is accessed to
> > safely modify the stack.  One reason for this is that it's frequently
> > tough to determine whether a memory store/load accesses the stack or
> > not.  And even if we know a stack access is occurring, it is often
> > difficult to determine where on the stack is being accessed.  As a
> > result, our current StackMod implementation is unable to modify ~50%
> > of otherwise instrumentable functions.  Our current efforts are
> > focused on reducing this percentage.
> >
> > Specific approaches we've considered (and started working on) include:
> >    *  Reducing unnecessary conservativeness in our StackAnalysis
> > procedure
> >    *  Adding memory-tracking to StackAnalysis
> >    *  Limited interprocedural analysis to track stack pointers that
> > are passed between functions
> >
> > - Matt
> > ________________________________________
> > From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of Marc
> > Brünink <marc@xxxxxxxxx>
> > Sent: Thursday, January 07, 2016 9:52 PM
> > To: dyninst-api@xxxxxxxxxxx
> > Subject: [DynInst_API:] StackMod
> >
> > Dear all,
> >
> > I never used StackMod nor did I look at the code so far.
> > If I remember correctly Stackmod only works for x86* in rewriting mode.
> >
> > I was wondering why it is limited to rewriting, what are the
> > limitations, remaining open challenges etc.
> >
> > Marc
> >
> >
> > _______________________________________________
> > 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