From: Daniel Jacobowitz <drow@false.org>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] dcache.c cleanup
Date: Thu, 18 Sep 2008 22:05:00 -0000 [thread overview]
Message-ID: <20080918220427.GA1691@caradoc.them.org> (raw)
In-Reply-To: <20080917214444.625B81C777F@localhost>
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
next prev parent reply other threads:[~2008-09-18 22:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-17 21:45 Doug Evans
2008-09-18 22:05 ` Daniel Jacobowitz [this message]
2008-09-23 18:41 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080918220427.GA1691@caradoc.them.org \
--to=drow@false.org \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox