Re: RFA: ia64 portion of libunwind patch

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> 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