Re: RFA: patch to fix 'info dcache' crash

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Thoughts?

Andrew> 5.1 or 5.2?

Most likely 5.2.

>> * After that is done, I'd create a single 'target' dcache.  I'll
>> keep the infrastructure in dcache so that we'll be able to have
>> more than one dcache when/if GDB is extended to control to multiple
>> targets simultaneously.  In target_open, target_resume, etc. I'd
>> add calls to invalidate the 'target' dcache.

Andrew> This bit has me puzzled.  By 'target' dcache do you mean an
Andrew> extra one of those target layers?

No.  At present, the various targets that support the data cache
create their own dcache in their to_open() vector.  If dcache is moved
above the target vectors, we need a to create a new dcache
corresponding to the whole 'current_target' regardless of what
vector(s) are used to implement it.  initialize_targets() would create
this dcache, target_xfer_memory() and target_xfer_memory_partial()
would be modified to use the dcache instead of calling the
to_xfer_memory() vectors directly, etc.

It's been mentioned that we're taking GDB in the direction where it
will be able to debug more than one target simultaneously (for
example, debugging both the parent and child processes after a
fork()).  When we go there, I imagine we'll have more than one
'current_target' and thus more than one dcache.  Because of this, I'm
not planning on removing the ability to have more than one dcache in 
the system.

        --jtc

-- 
J.T. Conklin
RedBack Networks