[Ltrace-devel] [PATCH v2 0/8] MIPSEL o32 updates

Edgar E. Iglesias edgar.iglesias at gmail.com
Thu Sep 27 17:23:56 UTC 2012


On Thu, Sep 27, 2012 at 07:19:48PM +0200, Petr Machata wrote:
> edgar.iglesias at gmail.com writes:
> 
> > From: "Edgar E. Iglesias" <edgar at axis.com>
> >
> > This is the series I've been hacking on.
> 
> I pushed this to master.  Thanks for all the work!
> 
> > There are still issues with threaded apps.
> >
> > There are at least two issues:
> > 1. Singlestepping over breakpoints is not really thread safe, IIUC.
> 
> FWIW, Linux backend takes care of this.  We stop all threads before
> singlestepping.  That holds also when arch uses software singlestepping.
> 
> The logic for that is declared in sysdeps/linux-gnu/trace.h and
> implemented in the corresponding .c, and can be reused by an arch
> backend when deemed necessary.  PPC backend does that.
> 
> > 2. Waiting until function return until adding breakpoints to
> >    resolved addresses is to late and not thread safe.
> >
> > I plan to take a closer look at the watchpoint approach to eliminate nr 2
> > as Petr M suggested. Any suggestions on howto solve issue nr 1 are also
> > wellcome. Leaving the breakpoint inplace and emulating the insn might be
> > a last resort, but quite involved...
> 
> Yeah, GDB calls this displaced stepping.  This would be an interesting
> optimization--process under ltrace can perform pretty horibly, with all
> the context switches and singlestepping, and this would help a bit.  But
> it shouldn't be necessary from strictly the correctnes point of view.

Great, thanks a lot for the help!

Cheers,
Edgar



More information about the Ltrace-devel mailing list