Re: RFC: Two small remote protocol extensions

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> > > ????? Memory is shared between threads, isn't it so ????

> This is yet another long overdue problem (I had hope it was fixed in
> recent releases) -  gdb lumps together mult-process
> debugging with multi-tread debugging and it it does not
> excell in any of them.
You mean GNU/Linux?

> It seems to me that we have to handle multi-process debugging a-la
> vxWorks with a separate gdb instance per process and thus forget about it.
I guess you didn't mean GNU/Linux.

The GNU/Linux and Solaris thread implementation have a specific thread 
that they use when doing memory operations.  That behavour should 
certainly be extended across the remote protocol so that a remote server 
can more exactly mimic the behavour of a native GDB.  GDB's view of the 
target's address space is defined by what the target's process can see. 
 If the target's process can't see it, neither can GDB.

Should it be defined by ``Hg'' I guess that open to debate (current 
implementation doesn't do anything here).  However, I think it should be 
well defined.

> When reading or writing memory, gdb specifies a thread.  If it turns out
> > that the thread disappeared, GDB picks a thread, any thread (the
> > assumption being that all address spaces are pretty much similar).
> >
> > Mind you, I've seen thread implementations that implemented per-thread
> > local data using VM.
>
> It does not mean that everybody else should suffer, it is time to fix
> this youthful indiscretion.
Humor me.  So who is suffering?

Andrew