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
The overhead of (3) is the primary concern, but we would also have to do
both (1) and (2).