Re: [libunwind] Unwinding using the context passed to a signal handler (doesn't work)

[David Mosberger]

>>>>> On Wed, 24 Mar 2004 10:53:12 +0100, Johan Walles <address@hidden> said:

  Johan> You're just re-phrasing what I said.  The fact that it's
  Johan> possible to walk the stack to where getcontext() was called
  Johan> from isn't the same as having getcontext() return the CPU
  Johan> state of the call site.  Let's say I have the following
  Johan> program:

  Johan> 1 foo() {
  Johan> 2   getcontext();
  Johan> 3 }
  Johan> 4
  Johan> 5 main() {
  Johan> 6   foo();
  Johan> 7 }

  Johan> Inside of foo(), b0 will point to line 7.

Wrong.  On _entry_ to foo() b0 will point to line 7.  After the call
to getcontext(), b0 will point to line 3.

  Johan> 3. To compensate for this, unw_init_local() starts by
  Johan> unwinding the context it receives by one frame.

  >> It only does this on HP-UX.

  Johan> This code snippet from "src/ia64/Ginit-ia64.c" says otherwise:

  Johan> case UNW_IA64_IP: addr = &uc->uc_mcontext.sc_br[0]; break;

Not at all.  All this says is that the IP of the caller of
getcontext() is stored in sc_br[0].  Could it be stored in sc_ip
instead?  Sure.  What would it change?  Absolutely nothing.

  Johan> Asking for the IP returns b0, not the IP.  Looks like some
  Johan> sort of unwinding to me.

Look we can talk about semantics all day long but it's clear to me now
that you don't disagree about _what_ is stored by unw_getcontext().
Instead you seem to have a beef with _where_ it's stored.  Why this is
bothering you I still don't understand.  Like I said before, a signal
context is a very different animal from the ucontext_t returned by
unw_getcontext().  The former captures the "asynchronous state"
(mostly scratch register), the latter the "synchronous state" (mostly
preserved registers).

  Johan> So I still maintain that the implementation doesn't match the
  Johan> man-page, and that the implementation should be fixed.

I'm sorry that you feel there is an inconsistency.  Perhaps this would
convince you otherwise: if you do unw_getcontext() and print the IP
(or any other register) returned via unw_get_reg(), you'll see that
the state matches with the one that exists in the CPU after
unw_getcontext() returns.

If you want to build your own ucontext_t, that's fine, but you better
adhere to the conventions used by ia64 linux and that convention says
that the return pointer of getcontext() be saved in sc_br[0].

        --david