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


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