libunwind-devel
[Top][All Lists]
Advanced

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

Re: [libunwind] Unwinding using the context passed to a signal handler (


From: Young, Mark
Subject: Re: [libunwind] Unwinding using the context passed to a signal handler (doesn't work)
Date: Tue, 30 Mar 2004 19:33:16 -0800
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030711

David,
Sorry if I seem to be flogging a dead horse...

I think the critical knowledge of whether or not a sigcontext can be used to initialize an unwind cursor should be hidden in libunwind, and I would like to see libunwind provide a portable interface for signal handlers to initialize an unwind cursor positioned at the signal frame.

I accept your statement that on ia64 the only practical way within a signal handler to begin unwinding from the signal frame is to call unw_getcontext, call unw_init_local, and then call unw_step until unw_is_signal_frame returns true. That is how I think the proposed interface should be implemented on ia64. For OSes which save the entire machine state in sigcontext and where it is possible and potentially beneficial to use it to initialize an unwind cursor, the sigcontext received by the signal handler should be passed to the interface regardless of its actual usefulness to the implementation. With inlined or macro implementation of the interface, the sigcontext argument should have no effect when unnecessary.

--Mark



David Mosberger wrote:
On Fri, 26 Mar 2004 11:03:13 -0800, "Young, Mark" <address@hidden> said:
            

  Mark> David, Do all platforms make the same distinction between
  Mark> asynchronous (signal) and synchronous contexts?

Most platforms store the entire machine-state in a sigcontext.
Most platforms do not have 256+ registers to deal with.

  Mark> I like Johan's suggestion of an alternate unw_init_local
  Mark> interface (unw_init_from_signal_context_local) that takes the
  Mark> signal context as the starting point.

And I don't like it at all, because it won't work anyhow _unless_ you
first save the preserved state.  And if you have to do that anyhow,
unw_getcontext() is just as fast and much cleaner.

  Mark> From what you are saying, an ia64 implementation of this would
  Mark> have to ignore the signal context, call getcontext, and unwind
  Mark> until it found the signal frame.

It doesn't ignore the signal context, it's just that you start with
the preserved state returned by unw_getcontext() and then the
sigcontext() gets picked up later on.

  Mark> But is that true for all platforms?

No, but I certainly don't want to design an API that _requires_ saving
the full machine-state in sigcontext.

I find it kind of funny how we all claim to be after performance, but
then I get complaints about the key optimization that makes
signal-delivery fast on ia64 linux (in fact, comparable or even faster
than on x86 linux, which I think is quite an achievement considering
how much bigger the machine state is for ia64).  If you don't believe
me, try measuring signal delivery overhead on some other ia64 OSes.

	--david
  

reply via email to

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