This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

mudflap cache question


I just read the mudflap pdf file and wanted to know how the cache was implemented.
I looked at the code in mf-runtime.c and found the cache functions. The code for the
__mf_uncache_object looks strange to me however.
The code looks like:


static void
__mf_uncache_object (__mf_object_t *old_obj)
{
 /* Remove any low/high pointers for this object from the lookup cache.  */

 /* Can it possibly exist in the cache?  */
 if (LIKELY (old_obj->read_count + old_obj->write_count))
   {
     uintptr_t low = old_obj->low;
     uintptr_t high = old_obj->high;
     unsigned idx_low = __MF_CACHE_INDEX (low);
     unsigned idx_high = __MF_CACHE_INDEX (high);
     unsigned i;
     for (i = idx_low; i <= idx_high; i++)
       {
         struct __mf_cache *entry = & __mf_lookup_cache [i];
         /* NB: the "||" in the following test permits this code to
            tolerate the situation introduced by __mf_check over
            contiguous objects, where a cache entry spans several
            objects.  */
         if (entry->low == low || entry->high == high)
           {
             entry->low = MAXPTR;
             entry->high = MINPTR;
           }
       }
   }
}

__MF_CACHE_INDEX(ptr) is (ptr >> 2) & 0x3ff at startup.

Suppose we have an old_obj->low of 0x10000 and an old_obj->high of 0x20000. Then the
cache entries we look at is just entry 0. Which I believe is just wrong. Any pointer
between 0x10000 and 0x20000 must fill other cache entries. It gets even worse when
the old_obj->low = 0x1fff0 and object high is 0x20000. Then we probably won't
invalidate any cache entry.
Should I write a bug report?


Herman.


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