This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
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.