new syscall stub support for ia64 libc

[David Mosberger]

>>>>> On Sat, 15 Nov 2003 01:38:05 -0800, David Mosberger <davidm@linux.hpl.hp.com> said:

  >> I still have some others failing (basic4, stack{1,2},
  >> cancelx{4,5,10,16,17,18}, cleanupx{0,1,3,4}, and oncex{3,4}), but
  >> I don't understand the problem there yet and I'll need to look
  >> into those next week.

The first problem was a stupid kernel bug in the light-weight handler
for sigprocmask.  I already pushed a fix for this to Linus and now
tst-basic4 as well as many other tests are working again.

The next genuine failure is in tst-cancelx4.  The problem here seems
to be due to the fact that unwind-c.c:__gcc_personality_v0 gets linked
statically into the test application, which pulls in the unwinder-code
from libgcc_eh.a (which, in my case, is the old, unwinder, not the
libunwind-based one).  But unwind-forcedunwind.c picks the unwinder up
via libgcc_s.so.1, which ends up using the libunwind-based unwinder,
so now I end up with two conflicting unwinders and when a context gets
passed from one unwinder to the other, bad things happen, of course.

Now I suppose you could argue that it's my inconsistent setup that's
the root-cause of the problem, but it worries me a bit to have
binaries that work correctly only if libgcc_s.so.1 matches with the
unwinder that was built statically into the application.  Effectively,
it would mean we could never change the contents of "struct
_Unwind_Context" without breaking binary compatiblity.  I don't think
that was intended?

Was the idea, perhaps, that the application's references to
_Unwind_*/__gcc_personality_v0 also get satisfied from libpthread?  If
so, I think those symbols would have to be exported.

Could you shed some light on how this is supposed to work?

Thanks,

	--david