Re: RFC: Two small remote protocol extensions

[Andrew Cagney <ac131313@ges.redhat.com>]

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

Andrew

(1) Above and beyond anything else, this is what a user wants to be fast.