[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. Thanks, PM _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
