Re: RFC: Two small remote protocol extensions

Daniel Jacobowitz
2002-08-28T16:49:29Z

On Wed, Aug 28, 2002 at 12:44:53PM -0400, Andrew Cagney wrote:
> >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 don't believe that it is even possible to measure a cache effect when
> profiling GDB's single step performance(1) --- other, far bigger, host
> or host<->target things things will drown any cache effects.
>
> Anyway, in case (a), since GDB won't be able to detect which thread was
> used to do the read --- the target is still free to use a thread, any
> thread.

I assume he meant GDB's dcache. Which is a real lifesaver, except when
it actually slows things down.

> >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.
>
> A target is always free to implement (b) using separate GDBs.

This is certainly true. HP even has fragmented code to do it natively.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer