Re: [libunwind] suggest adding unw_init_local_accessors

[David Mosberger]

>>>>> On Thu, 05 Dec 2002 21:06:43 -0800, Mark Young <address@hidden> said:

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

  Mark> The overhead of (3) is the primary concern, but we would also
  Mark> have to do both (1) and (2).

OK, if we fix (3), then (1) and (2) would improve as well.

  Mark> I intended the callback approach to supplement the
  Mark> pre-registration scheme, not replace it.

But a callback scheme (in the target address space) just doesn't work.
Consider that the application might have crashed or that it might have
been in the middle of a critical section (holding locks and whatnot).
It's just not possible to safely execute a callback in that case.

  Mark> I think a third "code section" format for the unw_dyn_info_t
  Mark> union would work. It could provide a pointer to a callback
  Mark> function and perhaps an application-defined void* argument to
  Mark> be passed to it along with the address space, ip, and whatever
  Mark> else you think it might need. The function would return the
  Mark> entry point address and unwind info in some form. It couldn't
  Mark> just register the procedure because that would overlap with
  Mark> the code section address range.

I'm not sure I understand all the constraints/goals you have.  Could
you propose a table-format (for the registration callback) which would
be acceptable for your application?  Assuming your application
generates a bunch of (contiguous) procedures that share the same gp,
then registers them in one fell swoop, something like this perhaps:

        struct unw_dyn_proc_table {
                unw_word_t handler;
                unw_word_t table_length;
                struct {
                        unw_word_t start_ip;
                        const char *name;               /* procedure name */
                        unw_dyn_region_info_t *regions; /* region desc. */
                } table[1];  /* variable length array, as per table_length */
        };

This way, the per-procedure overhead would be limited to 24 bytes/procedure.

        --david