GDB protocol and threads

[Andrew Cagney]

[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