This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: why is gdb 5.2 so slow

From: "Nick Kelsey" <nickk at ubicom dot com>
To: <gdb at sources dot redhat dot com>
Date: Fri, 1 Nov 2002 08:36:36 -0800
Subject: Re: why is gdb 5.2 so slow
References: <20021101013219.QDL1261.amsfep12-int.chello.nl@there> <20021101035218.GA14509@nevyn.them.org> <20021101133135.LDS1274.amsfep14-int.chello.nl@there> <3DC2967B.8050603@redhat.com> <redirect-4290038@silicondust.com>

> Both.  Things we do wrong:
> - GDB can't handle being told that just one thread is stopped.  If we
> could, then we wouldn't have to stop all threads for shared library
> events; there's a mutex in the system library so we don't even have to
> worry about someone hitting the breakpoint.  We could also use this to
> save time on conditional breakpoints; if we aren't stopping, why stop
> all other threads?
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

We have exactly this problem at the moment - our system supports setting
breakpoints that only stop specified threads, however GDB cannot use this
support at the moment. If you have an interest for this support then I would
be interested in your thoughts.

Nick

Nick Kelsey
Senior Software Engineer
Ubicom

References:
- Re: why is gdb 5.2 so slow
  - From: wim delvaux
- Re: why is gdb 5.2 so slow
  - From: Andrew Cagney

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]