This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
- From: Quality Quorum <qqi at theworld dot com>
- To: Andrew Cagney <ac131313 at ges dot redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, <gdb at sources dot redhat dot com>
- Date: Fri, 23 Aug 2002 16:10:17 -0400
- Subject: Re: RFC: Two small remote protocol extensions
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