This is the mail archive of the 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: [PATCH 08/10] Don't invalidate dcache when option stack-cache is changed

I realize I didn't reply to this part, when I had meant to.

On 11/17/2013 09:44 PM, 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.

I definitely agree.

Actually, doesn't the patch actually introduce a bug, like:

#1 - enable stack cache
#2 - print stack variable
#3 - disable cache
#4 - write to variable.  As the cache is off, and

 @@ -1593,14 +1593,14 @@ memory_xfer_partial_1 (struct target_ops *ops, enum target_object object,

   /* Make sure the cache gets updated no matter what - if we are writing
      to the stack.  Even if this write is not tagged as such, we still need
 -     to update the cache.  */
 +     to update the cache.  Update the cache to keep it in sync if it
 +     has been initialized.  */

   if (res > 0
       && inf != NULL
       && writebuf != NULL
       && target_dcache_init_p ()
       && !region->attrib.cache
 -      && stack_cache_enabled ()
       && object != TARGET_OBJECT_STACK_MEMORY)

... we don't update the cache.

#5 - enable cache
#6 - print variable again.  The stale cached value is printed.


Pedro Alves

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