This is the mail archive of the gdb-patches@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]

Re: [RFA] dcache.c cleanup


On Wed, Sep 17, 2008 at 02:44:44PM -0700, Doug Evans wrote:
> IIRC, "set remotecache" isn't being removed to avoid breaking existing
> scripts.  It's not used for anything, so this patch marks it as deprecated,
> and hopefully in a future release we can delete it.
> [If folks want I can instead submit a patch that makes it useful again -
> e.g. as an escape hatch in case caching isn't working, it would globally
> override the mem attribute settings.]

Just my two cents, but I think that the command is useful (even if
currently broken) - before deprecating it we should have a good idea
of what to replace it with.  Maybe a non-target-specific command
and make this a deprecated alias to it.

Should we come up with a coherent picture of the different kinds of
memory accesses GDB needs?  This is something I've been thinking about
on and off.  Particular ideas:

- When we are doing prologue analysis, we use symbols from the
executable (either minimal or full symbols) to find function
boundaries.  Then we analyze forwards from there.  In every case I can
think of, this means that we should use the code as present in the
executable.  It's like trust-readonly-sections, but for only
prologue analysis reads; the manual disassemble command would still
show if any code had been corrupted.

- When reading data from the stack for unwinding, we can reliably
assume that the data is thread-specific and not volatile.  So we
should be able to cache it automatically, even without user
instruction, until that thread resumes.  This is like memory
attributes, but only for stack unwinding.

- If we have memory region descriptions, it's probably safe to assume
that we have the stack described as RAM.  This is like "set mem
inaccessible-by-default", but only for stack unwinding.

WDYT - do those make sense?

> 2008-09-17  Doug Evans  <dje@google.com>
> 
> 	* dcache.c (state_chars): New static global.
> 	(ENTRY_INVALID,ENTRY_VALID): Renamed from ENTRY_BAD,ENTRY_OK.
> 	All uses updated.
> 	(dcache_info): Print cache state as mnemonically useful letters instead
> 	of magic numbers.
> 	(_initialize_dcache): Mark "set remotecache" as deprecated.
> 	* doc/gdb.texinfo (info dcache): Update.

The changes other than to "set remotecache" look OK to me (remember
that doc has its own ChangeLog).

-- 
Daniel Jacobowitz
CodeSourcery


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