Re: new syscall stub support for ia64 libc

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On Tue, 18 Nov 2003 00:12:37 -0800, Ulrich Drepper <drepper@redhat.com> said:

  >> I tracked this down now and unfortunately it's a fundamental
  >> limitation of the the GCC ia64 unwinder:

  Uli> Well, I have to trust you on this.  No time to dive into all
  Uli> these details.

Sure.  For the record, here are some pointers to why this can't
work: the first clue is this line:

  fs->when_target = (context->rp - context->region_start) / 16 * 3;

This ignores the slot-number, which is OK as long as you do
synchronous unwinding only.  Of course, this by itself would
be trivial to fix.  Something like this would do:

  fs->when_target = ((context->rp & ~0xfUL) - context->region_start) / 16 * 3
	  + (context->rp & 0xf);

The next clue is in uw_update_reg_address(), where there is
stuff along the lines of:

    case UNW_WHERE_BR:
      /* Note that while RVAL can only be 1-5 from normal descriptors,
	 we can want to look at B0 due to having manually unwound a
	 signal frame.  */
      if (rval <= 5)
	addr = context->br_loc[rval];
      else
	abort ();
      break;

Here, you see that branch registers b6 and b7 (which are scratch regs)
are not handled at all.

Then, we can look at desc_abi(): it doesn't do anything, meaning the
unwinder won't be able to detect signal frames at all.

Other issues: that unwinder isn't able to resume execution at a point
that was interrupted by a signal (scratch regs won't get restored), is
known to be broken w.r.t. sigstack(), and cannot support dynamically
generated code.

So I think it's just time to give up on it (unless someone wants to
volunteer and fix those things up; but given that they already work
with libunwind, that seemsm like a wasted effort to me).

  >> For NPTL, I suppose that would mean to check whether the
  >> available unwinder can properly unwind across signal-handlers
  >> and, if so, enable the new syscall stubs.

  Uli> It's also a runtime issue.  We can certainly require a fixed
  Uli> libgcc_s with support for the external libunwind at compile
  Uli> time.  But it'll be a while until things are fixed correctly
  Uli> everywhere.

Hopefully it won't take too long.

  Uli> Jakub will know better how to handle the gcc side.  I'll defer
  Uli> to him providing such a gcc.  If it works and is acceptable, we
  Uli> can look at transitioning over to it.

I submitted some fix ups for GCC just yesterday.  With those, GCC
should be all sets.

The only outstanding issue for libc is the fact that it's linking in
libgcc_eh.a (even for dynamically linked apps).  I'm not convinced it
should and if it really does, it probably needs a way to figure out
what dependent libraries there might be (e.g., libunwind-enabled GCC
would need -lunwind along with -lgcc_eh).

	--david