RE: serious(?) glibc backtrace() problem on IA64

RE: serious(?) glibc backtrace() problem on IA64

[Boehm, Hans]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

> From: Andrew Haley [mailto:aph@cambridge.redhat.com]
>  > Is this fixed in other versions of glibc?  Should the 
> libjava configury
>  > stuff explicitly turn off HAVE_BACKTRACE? 
> 
> That sounds right.
> 
>  > If so, can an autoconf expert add that hack to at least the 3.1
>  > tree?
None seems to have spoken up, so how's the attached branch from a nonexpert?
I definitely want this in the branch; I'm less sure about the trunk.  If
it's approved, I would also appreciate a volunteer to regenerate configure
after I check it in, since I'm not sure I have the right version of
autoconf.
> 
>  > In the longer term, if this is still in glibc, it seems to 
> me that this is
>  > the wrong default for backtrace() on IA64.
> 
> I would prefer to use libunwind, to begin with for IA-64, and later
> for everything.
> 
No disagreement here.  I didn't state that quite right originally.  I think
one way or another, the current "generic" version of backtrace in glibc
should be disabled for IA64.  (Other platforms may have similar issues.)  An
implementation that fails in random ways seems to be the worst possible
placeholder.

Hans


[-- Attachment #2: backtrace.diff --]
[-- Type: application/octet-stream, Size: 919 bytes --]

Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/libjava/configure.in,v
retrieving revision 1.114.2.12
diff -u -r1.114.2.12 configure.in
--- configure.in	11 Apr 2002 22:20:43 -0000	1.114.2.12
+++ configure.in	18 Apr 2002 00:24:09 -0000
@@ -494,8 +494,19 @@
    AC_CHECK_FUNCS(nl_langinfo setlocale)
    AC_CHECK_FUNCS(inet_aton inet_addr, break)
    AC_CHECK_FUNCS(inet_pton uname inet_ntoa)
-   AC_CHECK_FUNCS(backtrace fork execvp pipe sigaction)
+   AC_CHECK_FUNCS(fork execvp pipe sigaction)
    AC_CHECK_HEADERS(execinfo.h unistd.h dlfcn.h) 
+   AC_CHECK_FUNC(backtrace, [
+     case "$host" in
+       ia64-*-linux*)
+	 # Has broken backtrace()
+	 ;;
+       *)
+         AC_DEFINE(HAVE_BACKTRACE)
+	 ;;
+     esac
+   ])
+
    AC_CHECK_LIB(dl, dladdr, [
      AC_DEFINE(HAVE_DLADDR)])
    AC_CHECK_FILES(/proc/self/exe, [

Re: serious(?) glibc backtrace() problem on IA64

[Tom Tromey]

>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> None seems to have spoken up, so how's the attached branch from
Hans> a nonexpert?  I definitely want this in the branch; I'm less
Hans> sure about the trunk.  If it's approved, I would also appreciate
Hans> a volunteer to regenerate configure after I check it in, since
Hans> I'm not sure I have the right version of autoconf.

I think this is fine.  It would be a bit better if we could really
test backtrace(), but I'm not too concerned about it, since in the
future we'll be moving to something else anyway.

I'm going to apply it and run autoconf and check it in.
Thanks.

Tom

serious(?) glibc backtrace() problem on IA64

[Andrew Haley]

Boehm, Hans writes:
 > Gcc 3.1 libjava seems to invoke the glibc backtrace() function
 > Throwable::fillInStackTrace whenever it appears to be available.
 > Unfortunately, at least my copy of glibc 2.2.4 seems to use the
 > sysdeps/generic implementation of backtrace() on IA64.  That
 > implementation in fact completely broken on IA64.  The end result
 > seems to be that mostly it quietly does nothing useful,
 > occasionally it generates an unaligned access, and even less
 > frequently it generates a SIGSEGV.

Right.  The libjava backtrace has been broken since the new gcc
unwinder went in.

 > Is this fixed in other versions of glibc?  Should the libjava configury
 > stuff explicitly turn off HAVE_BACKTRACE? 

That sounds right.

 > If so, can an autoconf expert add that hack to at least the 3.1
 > tree?

 > In the longer term, if this is still in glibc, it seems to me that this is
 > the wrong default for backtrace() on IA64.

I would prefer to use libunwind, to begin with for IA-64, and later
for everything.

Andrew.

serious(?) glibc backtrace() problem on IA64

[Boehm, Hans]

Gcc 3.1 libjava seems to invoke the glibc backtrace() function
Throwable::fillInStackTrace whenever it appears to be available.
Unfortunately, at least my copy of glibc 2.2.4 seems to use the
sysdeps/generic implementation of backtrace() on IA64.  That implementation
in fact completely broken on IA64.  The end result seems to be that mostly
it quietly does nothing useful, occasionally it generates an unaligned
access, and even less frequently it generates a SIGSEGV.

Is this fixed in other versions of glibc?  Should the libjava configury
stuff explicitly turn off HAVE_BACKTRACE?  If so, can an autoconf expert add
that hack to at least the 3.1 tree?

In the longer term, if this is still in glibc, it seems to me that this is
the wrong default for backtrace() on IA64.

Thanks.

Hans