This is the mail archive of the gdb-prs@sourceware.org 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]

gdb/2087: dcache cannot be enabled for some targets


>Number:         2087
>Category:       gdb
>Synopsis:       dcache cannot be enabled for some targets
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 20 07:38:01 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     tsewell@cse.unsw.edu.au
>Release:        GNU gdb 6.3
>Organization:
>Environment:
Debian GNU/Linux
>Description:
I've written some GDB stubs into a system that's running in a simulator. Needless to say, performance sucks. Caching would help a lot, so I've tried "set remotecache on", but nothing happens. The virtual serial line is echoed to a terminal, so I can actually see that requests are being repeated.

>From inspection of the GDB source, it seems that the issue is that the dcache mechanism is implicitly sidelined by the stratum mechanism in target.c: target_xfer_memory () knows to call the dcache if it is enabled, but target_read_memory() and target_write_memory() prefer to call xfer_using_stratum() which doesn't seem to trigger any dcache calls.

It would appear that the dcache mechanism has simply been sidelined by design changes in GDB and is now only called in the fallback situation. This really ought to be fixed: caching is crucial for extracting any significant amount of data from a remote target.
>How-To-Repeat:
> set remotecache on
connect to your favourite remote TCP target,
e.g. target remote :1234
> info dcache
observe that nothing is going into the dcache
>Fix:
Either dcache needs to be layered above the target_read/target_write mechanism and its multiple implementations, or all implementations must call it (i.e. the  stratum implementation must call it).

In either case, the dcache code may have to be extended to call back to the appropriate target specific code on a miss.

I'd be prepared to write the patch myself, since I need this working shortly, but I'm not sure what the best approach is. Input from anyone who knows about these designs.
>Release-Note:
>Audit-Trail:
>Unformatted:


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