* serious(?) glibc backtrace() problem on IA64
@ 2002-04-17 0:22 Boehm, Hans
2002-04-17 9:46 ` Andrew Haley
0 siblings, 1 reply; 4+ messages in thread
From: Boehm, Hans @ 2002-04-17 0:22 UTC (permalink / raw)
To: 'java@gcc.gnu.org'
Cc: 'tromey@redhat.com', 'drepper@redhat.com',
MOSBERGER, DAVID (HP-PaloAlto,unix3)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* serious(?) glibc backtrace() problem on IA64
2002-04-17 0:22 serious(?) glibc backtrace() problem on IA64 Boehm, Hans
@ 2002-04-17 9:46 ` Andrew Haley
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Haley @ 2002-04-17 9:46 UTC (permalink / raw)
To: Boehm, Hans
Cc: 'java@gcc.gnu.org', 'tromey@redhat.com',
'drepper@redhat.com',
MOSBERGER, DAVID (HP-PaloAlto,unix3)
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: serious(?) glibc backtrace() problem on IA64
2002-04-18 1:15 Boehm, Hans
@ 2002-04-19 17:18 ` Tom Tromey
0 siblings, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2002-04-19 17:18 UTC (permalink / raw)
To: Boehm, Hans
Cc: 'Andrew Haley', 'java@gcc.gnu.org',
'drepper@redhat.com',
MOSBERGER, DAVID (HP-PaloAlto,unix3)
>>>>> "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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: serious(?) glibc backtrace() problem on IA64
@ 2002-04-18 1:15 Boehm, Hans
2002-04-19 17:18 ` Tom Tromey
0 siblings, 1 reply; 4+ messages in thread
From: Boehm, Hans @ 2002-04-18 1:15 UTC (permalink / raw)
To: 'Andrew Haley', Boehm, Hans
Cc: 'java@gcc.gnu.org', 'tromey@redhat.com',
'drepper@redhat.com',
MOSBERGER, DAVID (HP-PaloAlto,unix3)
[-- 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, [
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-04-20 0:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-17 0:22 serious(?) glibc backtrace() problem on IA64 Boehm, Hans
2002-04-17 9:46 ` Andrew Haley
2002-04-18 1:15 Boehm, Hans
2002-04-19 17:18 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).