Re: [libunwind] suggest adding unw_init_local_accessors

[David Mosberger]

>>>>> On Thu, 05 Dec 2002 18:38:20 -0800, Mark Young <address@hidden> said:

  Mark> Yes, I can accomplish what I want by copying the accessors struct
  Mark> belonging to unw_local_address_space ...
  Mark> unw_accessors_t ac;
  Mark> unw_addr_space_t as;
  Mark> ac = *unw_get_accessors(unw_local_addr_space);
  Mark> ac.access_mem = my_access_mem;
  Mark> as = unw_create_addr_space(&ac);
  Mark> rc = unw_init_remote(&cursor), as, uc)

Good.

  Mark> I'm concerned by the removal of the acquire_unwind_info
  Mark> accessor function. The new dynamic unwind info registration
  Mark> scheme requires all active procedures to be registered before
  Mark> unwinding begins.

Yes, but to be more precise: they must be registered before they get
executed for the first time (this may seem like a trivial point, but
see the point below regarding debuggers).

  Mark> The list of registered dynamic procedures duplicates a similar
  Mark> list necessarily maintained by our application. I understand
  Mark> and appreciate how the underlying descriptor structure can be
  Mark> shared by all procedures with identical prologue/epilog code
  Mark> sequences, but the number of dynamic procedures can be very
  Mark> large (for example, when simulating a large chip design). I
  Mark> think it would be worthwhile to allow the application to
  Mark> manage the detailed list of dynamic procedures if it so
  Mark> chooses. In our case, the dynamic procedures are generated
  Mark> consecutively into large allocated blocks -- which suggests a
  Mark> compromise -- define some way to register a dynamic code
  Mark> section with a callback function to be used during an unwind
  Mark> step to obtain the procedure entry address and unwind info for
  Mark> any ip address that falls in the section.

I'd love to be able to have a callback approach, but unfortunately
this can't really work (reliably) for debuggers and anything else that
unwinds another process (unless the callback executes in the context
of the unwinder, which leads to the other problems discussed earlier).

What is your primary concern with registering, say, thousands of
procedures:

 (1) Overhead of calling _U_dyn_register()?  (An O(1) operation).

 (2) Overhead of calling _U_dyn_cancel() (An O(N) operation, N = number
     of registered procedures).

 (3) Space-overhead of needing a unw_dyn_info_t structure for each
     procedure (currently 72 bytes).

I hope that (1) is not a major concern, since generating the code is
relatively expensive (e.g., requires cache-flushing).  If you destroy
generated code with high frequency, (2) could be a real issue.  We
could move to a doubly-linked list to get (2) down to O(1), but that
would make a lock-free implementation more difficult/impossible.  If
it's (3), we should be able to add a third registration format which
provides a more efficient to register a group of procedures that are
contiguous.

        --david