Re: new syscall stub support for ia64 libc

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

Just a quick status-update: the new-syscall-stub-enabled libc now
passes all checks (apart from a previously-exiting locale-related
failure) and it all seems to work nice and stable.  The NPTL test
suite combined with the new syscall stubs turned out to be a really
tough test-case, because it stressed lots of things in ways that
wasn't possible before.  As a result, bugs got fixed in libc, gcc (one
still pending), libunwind, and the kernel.

The only outstanding issue now is that of libgcc_eh.a.  The problem is
that since libgcc_eh.a references the unwinder, you'll have to link in
-lunwind when linking in libgcc_eh.a.  My understanding is that
libgcc_eh.a should only be linked into statically-linked applications.
When doing so, linking in libunwind.a seems reasonable enough.
However, at the moment, the libc build environment seems to sometime
link libgcc_eh.a even into dynamically linked binaries and in that
case, you really don't want to have to link in libunwind.a.  For now,
I hacked around the problem by putting the libunwind.a members into
libgcc_eh.a, but that's of course not a clean solution.

A related issue: when building a statically linked binary, shouldn't
the NPTL unwinder also use the static libgcc_eh.a facilities, rather
than loading libgcc_s.so at runtime?  Doing the latter can result in
rather difficult to track down bugs when there is a version conflict
between libgcc_eh.a and libgcc_s.so.

Comments?

	--david