Re: new syscall stub support for ia64 libc

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

>>>>> On Mon, 17 Nov 2003 10:12:22 -0800, Ulrich Drepper <drepper@redhat.com> said:

  Uli> David Mosberger wrote:

  >> OK, it looks to me like the unwinder is failing.  I suspect it's
  >> choking either on the .altrp directive or on the unwind
  >> directives for the signal trampoline.

  Uli> But we already did unwind through signal handlers.  It must be
  Uli> something new your patch adds.  So likely the code in
  Uli> _dl_sysinfo_break, the .altrp etc.  If a signal is received the
  Uli> thread is usually in a syscall so we have to unwind through the
  Uli> signal handler frame, the sigreturn stuff, and then the frame
  Uli> around the break instruction.  It must be the step from
  Uli> sigreturn to _dl_sysinfo_break, everything else is the same.

I tracked this down now and unfortunately it's a fundamental
limitation of the the GCC ia64 unwinder: it assumes that unwinding
happens only at procedure-call-boundaries.  It never tracks any
scratch registers, which means it simply cannot properly unwind across
signal-handlers.  You may get lucky at times, but it can't work in
general.  The reason the new syscall stubs trigger this problem is
that the return-pointer gets saved in register b6, which is a scratch
register.  My suggestion is to deprecate the built-in GCC ia64
unwinder and to use libunwind instead.  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.

Does this sound reasonable?

	--david