[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