This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: patch to fix 'info dcache' crash
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: RFA: patch to fix 'info dcache' crash
- From: jtc at redback dot com (J.T. Conklin)
- Date: 11 Aug 2000 11:55:36 -0700
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <5m8zu5kk2r.fsf@jtc.redback.com> <39930144.47ADDC03@cygnus.com>
- Reply-To: jtc at redback dot com
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Want to be listed as ``dcache'' maintainer?
Sure, but after I fill you in on my plans you might not want me to...
At present, the dcache is beneath the target's xfer_memory function.
I'd like to hoist it up a level so it's between target_xfer_memory()
(and target_xfer_memory_partial()) and the target's xfer_memory
function. Then then dcache will be available for all targets without
requiring explicit support.
* To start, I'd rename dcache_flush() to dcache_invd() (or perhaps
dcache_invalidate(), what do you think?) :-)
* Then I'd change the dcache memory read and write functions to be a
single xfer_memory function with the same prototype as xfer_memory
vector function.
* 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.
* Finally since the memory functions were already modified in step 2,
it would be trival to move the cache up a level.
Thoughts?
--jtc
--
J.T. Conklin
RedBack Networks