This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: ia64 portion of libunwind patch
>>>>> On Fri, 31 Oct 2003 18:42:54 -0500, Andrew Cagney <ac131313@redhat.com> said:
>> On Fri, 31 Oct 2003 13:35:51 -0800, Marcel Moolenaar
>> <marcel@xcllnt.net> said:
>>
>>
Marcel> Since libunwind already does its own caching, we may be
Marcel> better off not caching in gdb.
>> That's true. However, note that by default, caching is not
>> enabled for remote unwinding (which is what gdb does). To enable
>> caching, gdb would have to make a call of the form:
>>
>> unw_set_caching_policy(ADDR_SPACE, UNW_CACHE_GLOBAL);
>>
>> Also, whenever something changes in the target that could
>> invalidate cached unwind info, gdb would have to call:
>>
>> unw_flush_cache(ADDR_SPACE, LO, HI);
>> where LO and HI is the address range that was affected (or LO=0,
>> HI=0 to flush the entire cache).
Andrew> Just FYI, for GDB, it will be better to let the target stack
Andrew> to do the cache management. That way the user can
Andrew> set/override the policy. For instance, in the case in
Andrew> question, the user would be inane to specify anything other
Andrew> than:
Andrew> (gdb) set trust-readonly-sections 1
Andrew> (which causes all read-only reads to be handled locally)
Andrew> this is also why the issue isn't really that much of a
Andrew> problem.
Just for clarification: note that libunwind doesn't cache the raw
bits. Instead, it caches the decoded unwind information, so it's
really a higher-level cache.
--david