[Top][All Lists]

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

Re: [libunwind] unwinding undescribed frames

From: David Mosberger
Subject: Re: [libunwind] unwinding undescribed frames
Date: Wed, 16 Jan 2002 22:08:43 -0800

>>>>> On Tue, 15 Jan 2002 14:31:31 -0800, Mark Young <address@hidden> said:

  Mark> Our digital simulation application generates and executes code
  Mark> dynamically. This code is called from and makes calls to other
  Mark> C functions. We have need to unwind down to stack frames of
  Mark> our own creation which do not have unwind descriptors and also
  Mark> to unwind through relocated stack and register backing
  Mark> store. Most of our needs appear to be met by the proposed
  Mark> unw_init_remote routine with accessor functions identified by
  Mark> the unw_accessors_t structure.

  Mark> It would help if the acquire_unwind_info accessor function
  Mark> could return some specific error code to terminate unwinding
  Mark> and cause a graceful and silent return from unw_step,
  Mark> preferably passing along that same error code. In our case
  Mark> this would be used when the ip passed to acquire_unwind_info
  Mark> falls in our dynamically generated code. We can handle
  Mark> unwinding through our undescribed frames and then restart the
  Mark> unwinder if a C function frame is reached. It would be nice
  Mark> not to have to use setjmp/longjmp to exit the unwinder as is
  Mark> presently necessary in the HP-UX ia64 unwind library
  Mark> implementation.

I don't see any reason why now.  Would a single error code suffice?
For now, I added error code UNW_ESTOPUNWIND for this purpose.  Any
other error code returned by acquire_unwind_info would also stop
unwinding, but may not be silent.

  Mark> Also I suggest that the application-specific data arg in the
  Mark> unw_accessors_t structure be passed to the acquire_unwind_info
  Mark> and release_unwind_info functions as it is for the access_mem,
  Mark> access_reg, access_fpreg, and resume functions. Wrapper
  Mark> functions could be added if necessary to drop the argument to
  Mark> call existing external routines.

Sounds like a good suggestion.  I'll make this change.



reply via email to

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