On Thu, Sep 27, 2012 at 07:19:48PM +0200, Petr Machata wrote: > [email protected] writes: > > > From: "Edgar E. Iglesias" <[email protected]> > > > > 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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
