libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libunwind] suggest adding unw_init_local_accessors


From: Mark Young
Subject: Re: [libunwind] suggest adding unw_init_local_accessors
Date: Fri, 06 Dec 2002 00:38:53 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

David Mosberger wrote:
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
  

If the application has crashed then the libunwind code itself is vulnerable when unwinding in the target address space. We understand the risk. All envisioned for the callback to do is search our existing data structures to find the prolog and epilog addresses corresponding to the given ip address and (ideally) return a pointer to a previously-initialized unwind  info structure.

Our procedures are usually but not always contiguous. If a code block fills up while generating code for a procedure, we allocate another block and insert a jump to the new block. Thus a single procedure may start in one block and end in another, and the end address may be less than the start address. The split occurs in the body of the procedure--never in the prolog or epilog sequence. Most prologs are alike and most epilogs are alike but the distance between them varies. Since we must maintain our own records to map source lines and statements to code addresses, I'd prefer not to burden libunwind with an elaborate and redundant data structure that might suit us but not work at all for the next user.
--Mark


reply via email to

[Prev in Thread] Current Thread [Next in Thread]