RE: Remaining Itanium exception, static linking patches

["Boehm, Hans" <hans_boehm at hp dot com>]

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.

Remind me why we can't unwind through the glibc signal handler wrapper?
That sounds like a bug for other reasons?  It should always be possible to
unwind.  (It currently isn't if you get a signal in the signal trampoline,
but David's unwind library should fix that.  Ditto for some other known
problems.)

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.

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

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.

Hans

> -----Original Message-----
> From: Andrew Haley [mailto:aph@cambridge.redhat.com]
> Sent: Thursday, March 14, 2002 11:00 AM
> To: Boehm, Hans
> Cc: 'java-patches@gcc.gnu.org'; 'tromey@redhat.com'
> Subject: Remaining Itanium exception, static linking patches
> 
> 
> Boehm, Hans writes:
>  > I already posted two messages about Itanium exception 
> handling issues that
>  > also affect C++ 
> (http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00806.html and
>  > http://gcc.gnu.org/ml/gcc/2002-03/msg00683.html )  This is 
> a list of the
>  > remaining (short) ones I have been using to compile 
> SPECjbb.  I think the
>  > first two originally came from Andrew Haley.
>  > 
>  > The first one turns on dwarf2-exception-style signal 
> handling for IA64.  The
>  > file naming here is probably suboptimal, since IA64 uses 
> unwind information
>  > separate from the debugging information, and thus AFAICT, 
> there is actually
>  > no relation to dwarf2.  But other than that this one should be
>  > uncontroversial.  I would like to check it in as is, into 
> both the trunk and
>  > branch.
> 
> There's one part of my patch that is evil in that it calls an internal
> glibc function.  The intention is to call the kernel directly to
> install the SEGV handler, rather than through glibc's wrapper.  [This
> is necessary because we can't unwind through glib'c signal handler
> wrapper.]  This internal glibc function might change or go away, and
> therefore calling it is the wrong thing to do.  I should fix this
> patch to use the proper syscall interface.
> 
> What is your kernel/glibc configuration?
> 
> Andrew.
>