This is the mail archive of the gdb@sourceware.org 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: Keeping breakpoints inserted


Thiago Jung Bauermann <bauerman at br.ibm.com> writes:
> On Sat, 2007-12-01 at 09:52 -0800, Jim Blandy wrote:
>> On Nov 30, 2007 5:30 PM, Michael Snyder <msnyder@specifix.com> wrote:
>> The original concern you raised was that non-stop debugging is "more
>> intrusive than we already are".  But clearly all-stop debugging on a
>> live system is maximally intrusive to the system's users; non-stop
>> debugging has the potential to be much less intrusive, when used with
>> knowledge of the interactions between the system's threads.
>
> There are cases when a developer will want to use non-stop debugging but
> minimize change of relative timing of threads. Suppose that a developer
> is trying to debug a deadlock situation in a program with 3 threads. A
> and B are deadlocking, and C is a "supporting" thread without which the
> other two can't run. He can't use all-stop debugging because while
> inspecting A and B, C needs to be running. In this case, relative timing
> of threads is important in order to have better chance at reproducing
> the deadlock.

Something that would be nice would be the ability to define "thread
groups", that you could stop and start as a group, restrict
breakpoints to, and so on.  You could put A and B in a thread group,
and leave C out of it.  That kind of feature would be straightforward
to implement in terms of the non-stop debugging we're doing now.


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