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


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.



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