new syscall stub support for ia64 libc
David Mosberger
davidm@napali.hpl.hp.com
Tue Nov 18 07:54:00 GMT 2003
>>>>> 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
More information about the Libc-hacker
mailing list