This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]