This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 08/10] Don't invalidate dcache when option stack-cache is changed
- From: Yao Qi <yao at codesourcery dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 18 Nov 2013 22:00:35 +0800
- Subject: Re: [PATCH 08/10] Don't invalidate dcache when option stack-cache is changed
- Authentication-results: sourceware.org; auth=none
- References: <1383458049-20893-1-git-send-email-yao at codesourcery dot com> <1383458049-20893-9-git-send-email-yao at codesourcery dot com> <CADPb22Q95Hfz1NOreFPwbrSnqjKQcXdYxbWc04zX1LG3MnJrYQ at mail dot gmail dot com>
On 11/18/2013 05:44 AM, Doug Evans wrote:
If one wanted to remove the cache invalidation for the off->on
transition that seems reasonable, but if I do a backtrace, turn the
caching optimization off, and then do another backtrace, I'd want the
second one to not use the cache. YMMV.
This behaviour is what we proposed in this patch.
OTOH, if there was a command I could use to flush the cache after
turning off the stack cache optimization, then I could see leaving the
cache alone after the on->off transition. [I still think it'd be
preferable to invalidate the cache, but I can live with asking users
to live with having to manually flush the cache after turning off the
optimization.]
IMO, cache to target memory is quite transparent to users. I can't
find a case that user has to flush or invalidate cache.
With this patch, we are lack of a way to flush the cache. I prefer to
add a new command to explicitly invalidate cache like "cache invalidate"
or "maint cache invalidate", if we think users really need this command.
--
Yao (éå)