Re: TARGET_SIGNAL_TRAP

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Jul 17, 2003 at 11:29:44AM -0700, David Carlton wrote:
> Some users here have noted that they have a hard time debugging
> multithreaded code in GDB.  We're assuming that it's probably a bug in
> our code instead of in GDB: it's just that GDB is changing the timing
> of the threads in ways that expose a latent bug in our code.
> 
> Which made me curious: why does GDB change the timing of programs?  I
> set a breakpoint in handle_inferior_event, and I see all these events
> claiming to be TARGET_SIGNAL_TRAPs.  But I haven't set any breakpoints
> or watchpoints!  So what causes all these traps to be generated?  Or
> am I misunderstanding the situation?  (I'm not at all sure that this
> is specific to multithreaded code - it may just be that its effects
> are most pronounced for multithreaded code, because single-threaded
> code doesn't have as much timing to be thrown off.)

Every time that a breakpoint is hit, including one breakpoint set at
every shared library load/unload, thread creation, or sometimes thread
exit, all threads are stopped and restarted.  That's the usual cause.

Signals also stop the process.  If GDB isn't going to report the signal
then it doesn't stop all threads, but that does interfere with timing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer