This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: per thread breakpoints
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: per thread breakpoints
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Wed, 1 Nov 2000 09:53:23 -0500 (EST)
- cc: gdb at sourceware dot cygnus dot com
On Wed, 1 Nov 2000, Andrew Cagney wrote:
> Quality Quorum wrote:
> >
> > Hi,
> >
> > It seems to me that gdb core does NOT seriously support per thread breaks:
> >
> > 1. target_insert_breakpoint() is unaware about thread associated with
> > a breakpoint.
>
> Yes. The original thread model was developed on systems that didn't
> have kernel level threads (it wasn't SMP either :-). Various
> assumptions were made such as it wasn't actually possible to set a
> breakpoint on a specific thread. Instead all breakpoints were set
> globally.
>
> > 2. insert_breakpoints() does not do any dances with inferior pids before
> > and after calls to target_insert_breakpoint().
> >
> > I would suppose it should be fixed ASAP (e.g. by adding pid argument to
> > to the target_insert_breakpoint): it is a huge resource hog in
> > case of remote debugging and it seems like linux threads would also
> > greatly benefit from this improvement.
>
> I don't think it is that easy. I recently looked through the thread
> code to see what would need changing. At present GDB makes all sorts of
> assumptions about breakpoints and their sideeffects. From memory,
> things like the way GDB iterates over breakpoints and resolves
> duplicates would also need to be changed.
>
> Rather than a simplistic tweek, I think there needs to be a clear robust
> thread model that GDB can map onto all real thread implementations.
Again, it seems to me as an urgent issue.
>
> Andrew
>
Thanks,
Aleksey