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: Wed, 28 Aug 2002 11:31:25 -0400
- Subject: Re: RFC: Two small remote protocol extensions
On Tue, 27 Aug 2002, Andrew Cagney wrote:
>
> >> > 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.
>
> Why are ``all things embedded'' suffering?
>
> I know of two cases:
>
> a) The threads have a 100% shared address space. Binding memory
> accesses to a thread will make zero difference.
>
> b) The threads do not have a 100% shared address space. Binding memory
> accesses to a thread will at least make it better reflect GDB's view of
> a threads address space.
>
Forcing model (b) on underlying environment (a) will force unnecessary
invalidations of memory cache and will pretty negatively affect
performance of a debugging session.
I would perefer to treat (b) as a separate process (and run separate gdb
instance to debug it a-la vxWorks and normal multi process debugging),
however, it will be fine to make this thing a configurable run time
parameter. At the sime time of forcing (a) to emulate (b) does not seem
appropriate.
> Andrew
>
>
Thanks,
Aleksey