RE: Remaining Itanium exception, static linking patches

[Andrew Haley <aph at cambridge dot redhat dot com>]

Boehm, Hans writes:
 > Andrew -
 > 
 > Thanks for the reply.
 > 
 > What, if anything, breaks if you don't apply that part of the patch and use
 > syscall(SYS_sigaction, ...)?  I haven't tried it, but if it works elsewhere,
 > it should probably work on IA64.

It should work; I haven't tried.

 > Remind me why we can't unwind through the glibc signal handler wrapper?

Actually, it probably isn't a problem on IA-64, but on most of our
targets glibc isn't built with unwind info.  I've discussed this with
Uli -- it is a known problem.

 > I'm actually not sure what's the greater sin here either:  Accessing a libc
 > internal symbol or counting on the fact that syscall (which I think is
 > basically not standardized) is not correctly intercepted by the thread
 > library.  We're counting on very implementation-specific behavior either
 > way.

Yes, but historically speaking the syscall interface changes less
frequently than the internals of glibc... hopefully!

Anyway, if IA-64 glibc is compiled with full unwind info there'll not
be a problem, and we can use the proper sigaction() interface and get
rid of the nastiness altogether.

 > Incidentally, the garbage collector already has a weak reference to
 > __libc_stack_end.  It seemed safer than the alternatives.

Yes...

 > I'm running mostly kernel version 2.4.5, and glibc version 2.2.4.  As I
 > remember, glibc 2.2.4 is necessary for gcc3.1 on Itanium, and kernel 2.4.x
 > is probably also a safe assumption.

Right, thanks.

Andrew.