This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB protocol and threads
- To: Quality Quorum <qqi at world dot std dot com>
- Subject: Re: GDB protocol and threads
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 18 Sep 2001 00:35:59 -0400
- Cc: gdb at sources dot redhat dot com
- References: <Pine.SGI.4.30.0109061518100.276-100000@world.std.com>
[1.5 hands]
> Hi,
>
> It seems to me that there is no point in making GDB protocol
> thread aware. I suppose that it will be much more preferable
> to add OS support unit instead. OS support would be able to
> figure out thread information by simply reading memory on the CPU
> side.
>
> Rationale:
>
> 1. It would keep things as simple as they are right now.
> 2. It would be compatible with dumb interfaces (e.g. BDM).
> 3. At 115Kbps performance impact will quite insignificant.
>
> The only per thread thing worth leaving should be stopped thread
> info and per thread breakpoints (later one need clean-up though).
>
> Thanks,
Unfortunately it isn't that black and white. Both solutions are equally
valid and GDB should, I think, accomodate both. Two examples come to mind:
-
GDB debuging SMP hardware
Here there is little choice, the hardware really does
have multiple theads so trying to pretend otherwise
is kind of silly.
-
GDB debugging something like linux threads
So in theory you could integrate the thread-db code into
gdb. in reality i don't think that battle is worth
fighting. intead just integrating it into gdbserver
would be sufficient - separate out the problem
andrew