RFC: Two small remote protocol extensions

[Quality Quorum]

On Fri, 23 Aug 2002, Andrew Cagney wrote:

>
> >> > ????? 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?

All things embedded and I suppose it is a much bigger market/user group
than ***ix one.

>
> Andrew
>
>

Thanks,

Aleksey