Nabble - gcc - java - patches

libjava: fix rebuild failure due to FFLAGS setting

2009-12-14T12:35:54Z

Since libjava/libltdl is still using old Libtool, it falls prey of the
old bug that tests for C++ and Fortran are run even if the package in
question (here: libltdl) does not use these languages at all. This
causes one interesting rebuild failure in the GCC tree: in an up to date
tree,
touch $srcdir/libjava/libltdl/configure

(which can implicitly happen through ./contrib/gcc_update), causes a
failure like this (sorry for the long line):

Making all in libltdl
make[5]: Entering directory `/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libjava/libltdl'
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ../../../../../gcc/libjava/libltdl/configure --disable-option-checking --prefix=/tmp/gcc-inst --with-multisubdir=32 --with-multisrctop= --enable-multilib --enable-maintainer-mode --with-boot-ldflags=-Wl,--as-needed --with-stage1-ldflags=-Wl,--as-needed --with-libelf=/tmp/gcc-inst --enable-lto --without-cloog --without-ppl --with-mpc=/tmp/gcc-inst --enable-languages=c,c++,fortran,java,lto,objc,obj-c++ --program-transform-name=s,y,y, --with-target-subdir=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu CC=/tmp/gcc/build/./gcc/xgcc -B/tmp/gcc/build/./gcc/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/sys-include CFLAGS=-g -O2 LDFLAGS= CPPFLAGS= CXX= /tmp/gcc/build/./gcc/xgcc -shared-libgcc -B/tmp/gcc/build/./gcc -nostdinc++ -L/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/sys-include CXXFLAGS=-g -O2 -D_GNU_SOURCE --enable-ltdl-convenience --with-vm-classes=/tmp/gcc/gcc/libjava:/tmp/gcc/build/x86_64-unknown-linux-gnu/libjava CC=/tmp/gcc/build/./gcc/xgcc -B/tmp/gcc/build/./gcc/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/sys-include -m32 CXX=/tmp/gcc/build/./gcc/xgcc -shared-libgcc -B/tmp/gcc/build/./gcc -nostdinc++ -L/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/sys-include -m32 F77= -m32 GCJ=/tmp/gcc/build/./gcc/gcj -B/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libjava/ -B/tmp/gcc/build/./gcc/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/sys-include -m32 GFORTRAN=/tmp/gcc/build/./gcc/gfortran -B/tmp/gcc/build/./gcc/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-inst/x86_64-unknown-linux-gnu/sys-include -m32 LD_LIBRARY_PATH=/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/.libs:/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libmudflap/.libs:/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libssp/.libs:/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libgomp/.libs:/tmp/gcc/build/./gcc:/tmp/gcc/build/./prev-gcc:/tmp/gcc-inst/lib:/tmp/gcc-inst/lib64 --disable-tool-wrappers --disable-load-library --disable-debug --enable-default-toolkit= --with-vm-classes=/tmp/gcc/gcc/libjava:/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libjava --disable-core-jni --disable-examples --with-glibj=build --disable-gconf-peer --enable-default-preferences-peer=gnu.java.util.prefs.FileBasedFactory --disable-gtk-peer --disable-plugin --disable-qt-peer --without-escher --disable-gjdoc --disable-regen-headers --disable-Werror --with-auxdir=/tmp/gcc/gcc --cache-file=../config.cache --srcdir=../../../../../gcc/libjava/libltdl --no-create --no-recursion
configure: loading cache ../config.cache
configure: error: `FFLAGS' was not set in the previous run
configure: error: in `/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libjava/libltdl':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ../config.cache' and start over
make[5]: *** [config.status] Error 1
make[5]: Leaving directory `/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libjava/libltdl'

The workaround for 1.5.x
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/6579>
works here as well, both cutting down on libltdl/configure run time and
size as well as avoiding this bug.

Another workaround would be to declare FFLAGS as precious in
libjava/configure.ac, but what's the point, as nothing below libjava
uses this variable.

OK for trunk? Bootstrapped i686-pc-linux-gnu without regressions.

(While this patch isn't in upstream Libtool branch-1-5, if you care
about it I can propose it upstream; the master branch has other code
with a similar effect.)

With this and the other recent patch in, I am not aware of any further
rebuilding glitches.

Thanks,
Ralf

Disable libtool support for languages unused in libjava/libltdl

libjava/libltdl/ChangeLog:
2009-12-13 Ralf Wildenhues <Ralf.Wildenhues@...>

* configure.ac: Disable libtool support for unused languages,
to avoid precious FFLAGS recheck cache consistency failure.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* Makefile.in: Regenerate.

diff --git a/libjava/libltdl/configure.ac b/libjava/libltdl/configure.ac
index 7e26e20..8631bd1 100644
--- a/libjava/libltdl/configure.ac
+++ b/libjava/libltdl/configure.ac
@@ -19,6 +19,10 @@

AC_PREREQ(2.64)

+dnl Disable libtool 1.5 support for languages we don't use
+define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl
+define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl
+define([AC_LIBTOOL_LANG_GCJ_CONFIG], [:])dnl

## ------------------------ ##
## Autoconf initialisation. ##

RE: [patch] use of atomic builtins for arm-linux-eabi in boehm-gc

2009-12-14T10:31:16Z

> From: Matthias Klose
>
> On 09.12.2009 11:16, Richard Earnshaw wrote:
> >> Current trunk fails to build on arm-linux-gnueabi in
> boehm-gc, when
> >> configured
> >> --with-mode=thumb:
> >>
> >> /tmp/ccVpqOWm.s: Assembler messages:
> >> /tmp/ccVpqOWm.s:1160: Error: selected processor does not
> support `swp
> >> r3,r3,[r2]'
> >> /tmp/ccVpqOWm.s:2472: Error: selected processor does not
> support `swp
> >> r3,r3,[r2]'
> >> /tmp/ccVpqOWm.s:3232: Error: selected processor does not
> support `swp
> >> r3,r3,[r2]'
> >> make[5]: *** [alloc.lo] Error 1
> >>
> >> arm-linux-gnueabi now provides the atomic builtins; use them
> >> unconditionally (as libjava does).
> >>
> >> Ok for the trunk, if testing succeeds? The build on trunk
> configured
> >> with --with-mode=thumb fails for other reasons (PR42093),
> currently
> >> testing the patch for the 4.4 branch.
> > 2009-12-09 Matthias Klose<doko@...>
> >
> > * include/private/gc_locks.h: For __ARM_EABI__ define
> > GC_test_and_set GC_clear to use the atomic builtins.
> >
> > OK for trunk once testing is complete.
>
> a test build did suceed without regressions. now that the
> _sync_synchronise fix is backported to the 4.4 branch, ok to
> commit to 4.4 branch as well?
>
> > Please also notify the upstream maintainer of boehm-gc, or
> this patch
> > may get lost in a future merge.
>
> forwarded to Hans Boehm.
>
> Matthias
>

Thanks for forwarding.

Since the upstream version now uses libatomic_ops, this code doesn't really exist there anymore.

If anyone wants to double check that the code there makes sense, you can find the gcc/arm dependent code in http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/libatomic_ops/src/atomic_ops/sysdeps/gcc/arm.h?revision=1.1&view=markup

My long term plan is to convert all of this to C++0x/C1x atomics, once those are sufficiently supported.

Hans

Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

2009-12-13T15:42:57Z

On 11.12.2009 10:57, Paolo Carlini wrote:

> On 12/11/2009 05:19 AM, Matthias Klose wrote:
>> the attached patch enables the link tests on linux, kfreebsd, and hurd
>> targets. checked with the (Debian) kfreebsd and hurd maintainers that
>> this is the right thing to do (although there doesn't exist an active
>> port of these on arm or hppa. tested on i486-linux-gnu,
>> arm-linux-gnueabi and hppa-linux-gnu. ok for the trunk?
> First, thanks Matthias for your patience on this issue.
>
> The patch looks very nice to me, just wait one day or so for comments
> and then go ahead, patch is approved for mainline.
>
> If you want, I would suggest adding a one-line comment in the code, say,
> after " # Do link tests if possible, instead asm tests, limited to some
> platforms", mentioning the PRs, these thorny issues about libgcc...

updated the comment, enabled link tests for *-*-uclinux* as suggested by Joseph,
committed to trunk.

Matthias

libstdc++-v3/

2009-12-11 Paolo Carlini <paolo.carlini@...>
Matthias Klose <doko@...>

PR libstdc++/40133
* acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*,
*-*-uclinux*, *-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when
possible.
* configure: Regenerate.

Index: libstdc++-v3/acinclude.m4
===================================================================
--- libstdc++-v3/acinclude.m4 (revision 155196)
+++ libstdc++-v3/acinclude.m4 (working copy)
@@ -2438,8 +2438,7 @@
dnl that are used should be checked.
dnl
dnl Note:
-dnl libgomp and libgfortran do this with a link test, instead of an asm test.
-dnl see: CHECK_SYNC_FETCH_AND_ADD
+dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD.
dnl
dnl Defines:
dnl _GLIBCXX_ATOMIC_BUILTINS_1
@@ -2451,12 +2450,122 @@
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
old_CXXFLAGS="$CXXFLAGS"
-
+
+ # Do link tests if possible, instead asm tests, limited to some platforms
+ # see discussion in PR target/40134, PR libstdc++/40133 and the thread
+ # starting at http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00322.html
+ atomic_builtins_link_tests=no
+ if test x$gcc_no_link != xyes; then
+ # Can do link tests. Limit to some tested platforms
+ case "$host" in
+ *-*-linux* | *-*-uclinux* | *-*-kfreebsd*-gnu | *-*-gnu*)
+ atomic_builtins_link_tests=yes
+ ;;
+ esac
+ fi
+
+ if test x$atomic_builtins_link_tests = xyes; then
+
+ # Do link tests.
+
+ CXXFLAGS="$CXXFLAGS -fno-exceptions"
+
+ AC_MSG_CHECKING([for atomic builtins for bool])
+ AC_CACHE_VAL(glibcxx_cv_atomic_bool, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef bool atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_bool=yes],
+ [glibcxx_cv_atomic_bool=no])
+ ])
+ if test $glibcxx_cv_atomic_bool = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
+ [Define if builtin atomic operations for bool are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_bool)
+
+ AC_MSG_CHECKING([for atomic builtins for short])
+ AC_CACHE_VAL(glibcxx_cv_atomic_short, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef short atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_short=yes],
+ [glibcxx_cv_atomic_short=no])
+ ])
+ if test $glibcxx_cv_atomic_short = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
+ [Define if builtin atomic operations for short are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_short)
+
+ AC_MSG_CHECKING([for atomic builtins for int])
+ AC_CACHE_VAL(glibcxx_cv_atomic_int, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef int atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_int=yes],
+ [glibcxx_cv_atomic_int=no])
+ ])
+ if test $glibcxx_cv_atomic_int = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
+ [Define if builtin atomic operations for int are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_int)
+
+ AC_MSG_CHECKING([for atomic builtins for long long])
+ AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef long long atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_long_long=yes],
+ [glibcxx_cv_atomic_long_long=no])
+ ])
+ if test $glibcxx_cv_atomic_long_long = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
+ [Define if builtin atomic operations for long long are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
+
+ else
+
+ # Do asm tests.
+
# Compile unoptimized.
CXXFLAGS='-O0 -S'

- # Fake what AC_TRY_COMPILE does, without linking as this is
- # unnecessary for a builtins test.
+ # Fake what AC_TRY_COMPILE does.

cat > conftest.$ac_ext << EOF
[#]line __oline__ "configure"
@@ -2478,14 +2587,14 @@
AC_MSG_CHECKING([for atomic builtins for bool])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinsb=no
+ glibcxx_cv_atomic_bool=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
[Define if builtin atomic operations for bool are supported on this host.])
- enable_atomic_builtinsb=yes
+ glibcxx_cv_atomic_bool=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinsb)
+ AC_MSG_RESULT($glibcxx_cv_atomic_bool)
rm -f conftest*

cat > conftest.$ac_ext << EOF
@@ -2508,14 +2617,14 @@
AC_MSG_CHECKING([for atomic builtins for short])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinss=no
+ glibcxx_cv_atomic_short=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
[Define if builtin atomic operations for short are supported on this host.])
- enable_atomic_builtinss=yes
+ glibcxx_cv_atomic_short=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinss)
+ AC_MSG_RESULT($glibcxx_cv_atomic_short)
rm -f conftest*

cat > conftest.$ac_ext << EOF
@@ -2539,14 +2648,14 @@
AC_MSG_CHECKING([for atomic builtins for int])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinsi=no
+ glibcxx_cv_atomic_int=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
[Define if builtin atomic operations for int are supported on this host.])
- enable_atomic_builtinsi=yes
+ glibcxx_cv_atomic_int=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinsi)
+ AC_MSG_RESULT($glibcxx_cv_atomic_int)
rm -f conftest*

cat > conftest.$ac_ext << EOF
@@ -2569,22 +2678,23 @@
AC_MSG_CHECKING([for atomic builtins for long long])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinsll=no
+ glibcxx_cv_atomic_long_long=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
[Define if builtin atomic operations for long long are supported on this host.])
- enable_atomic_builtinsll=yes
+ glibcxx_cv_atomic_long_long=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinsll)
+ AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
rm -f conftest*

+ fi

CXXFLAGS="$old_CXXFLAGS"
AC_LANG_RESTORE

# Set atomicity_dir to builtins if either of above tests pass.
- if test $enable_atomic_builtinsi = yes || test $enable_atomic_builtinsb = yes ; then
+ if test $glibcxx_cv_atomic_int = yes || test $glibcxx_cv_atomic_bool = yes ; then
atomicity_dir=cpu/generic/atomicity_builtins
fi

Re: [patch] use of atomic builtins for arm-linux-eabi in boehm-gc

2009-12-13T15:24:54Z

On 09.12.2009 11:16, Richard Earnshaw wrote:

>> Current trunk fails to build on arm-linux-gnueabi in boehm-gc, when
>> configured
>> --with-mode=thumb:
>>
>> /tmp/ccVpqOWm.s: Assembler messages:
>> /tmp/ccVpqOWm.s:1160: Error: selected processor does not support `swp
>> r3,r3,[r2]'
>> /tmp/ccVpqOWm.s:2472: Error: selected processor does not support `swp
>> r3,r3,[r2]'
>> /tmp/ccVpqOWm.s:3232: Error: selected processor does not support `swp
>> r3,r3,[r2]'
>> make[5]: *** [alloc.lo] Error 1
>>
>> arm-linux-gnueabi now provides the atomic builtins; use them
>> unconditionally (as
>> libjava does).
>>
>> Ok for the trunk, if testing succeeds? The build on trunk configured
>> with
>> --with-mode=thumb fails for other reasons (PR42093), currently testing
>> the patch
>> for the 4.4 branch.
> 2009-12-09 Matthias Klose<doko@...>
>
> * include/private/gc_locks.h: For __ARM_EABI__ define
> GC_test_and_set GC_clear to use the atomic builtins.
>
> OK for trunk once testing is complete.

a test build did suceed without regressions. now that the _sync_synchronise fix
is backported to the 4.4 branch, ok to commit to 4.4 branch as well?

> Please also notify the upstream maintainer of boehm-gc, or this patch may
> get lost in a future merge.

forwarded to Hans Boehm.

Matthias

Re: [patch] Fix libffi.call/cls_align_pointer.c on Solaris < 10

2009-12-11T14:28:57Z

> This seems to call for a more general solution than this hack, probably
> along the lines of intl/loadmsgcat.c.

No hack here, just a kludge similar to the one just above.

--
Eric Botcazou

Re: [patch] Fix libffi.call/cls_align_pointer.c on Solaris < 10

2009-12-11T13:43:16Z

Eric Botcazou <ebotcazou@...> writes:

> libffi.call/cls_align_pointer.c fails to compile on Solaris < 10 because
> PRIuPTR is not defined. Hence the attached kludge.
>
> Tested on SPARC/Solaris 9 and SPARC/Solaris 10, OK for mainline?
>
>
> 2009-12-11 Eric Botcazou <ebotcazou@...>
>
> * testsuite/libffi.call/ffitest.h: Define PRIuPTR on Solaris < 10.
[...]
> +/* Solaris < 10 kludge. */
> +#if defined(__sun__) && defined(__svr4__) && !defined(PRIuPTR)
> +#if defined(__arch64__) || defined (__x86_64__)
> +#define PRIuPTR "lu"
> +#else
> +#define PRIuPTR "u"
> +#endif
> +#endif

The same problem exists on other platforms as well, e.g. Tru64 UNIX
V4.0F (which even lacks %lld/%llu support in libc, but has 64-bit long)
and V5.1B (which has %lld/%llu, but lacks the C99 PRI* macros). Cf. PR
libffi/40701.

This seems to call for a more general solution than this hack, probably
along the lines of intl/loadmsgcat.c.

Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

2009-12-11T02:24:14Z

On Fri, 11 Dec 2009, Matthias Klose wrote:

> On 09.12.2009 11:50, Paolo Carlini wrote:
> > On 12/09/2009 11:42 AM, Matthias Klose wrote:
> > > would a patch acceptable to run these link tests on linux only?
> >
> > Sure. If you can cook up something (e.g, a version of the configure code
> > I wrote at the time) running only where it's safe to run it (I think
> > linux targets are all safe), fine with me!
>
> the attached patch enables the link tests on linux, kfreebsd, and hurd
> targets. checked with the (Debian) kfreebsd and hurd maintainers that this is

Link tests are also safe for libstdc++ to use for uclinux targets.

--
Joseph S. Myers
joseph@...

Fix libffi.call/cls_longdouble_va.c on SPARC64

2009-12-11T02:07:07Z

We forgot that 'long double' are quad-aligned on SPARC64.

Tested on SPARC64/Solaris 10, applied on the mainline.

2009-12-11 Eric Botcazou <ebotcazou@...>

* src/sparc/ffi.c (ffi_closure_sparc_inner_v9): Properly align 'long
double' arguments.

--
Eric Botcazou

[sparc_libffi.diff]

Index: src/sparc/ffi.c =================================================================== --- src/sparc/ffi.c (revision 155123) +++ src/sparc/ffi.c (working copy) @@ -599,6 +599,11 @@ ffi_closure_sparc_inner_v9(ffi_closure * /* Right-justify. */ argn += ALIGN(arg_types[i]->size, FFI_SIZEOF_ARG) / FFI_SIZEOF_ARG; + /* Align on a 16-byte boundary. */ +#if FFI_TYPE_LONGDOUBLE != FFI_TYPE_DOUBLE + if (arg_types[i]->type == FFI_TYPE_LONGDOUBLE && (argn % 2) != 0) + argn++; +#endif if (i < fp_slot_max && (arg_types[i]->type == FFI_TYPE_FLOAT || arg_types[i]->type == FFI_TYPE_DOUBLE

Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

2009-12-11T01:57:43Z

On 12/11/2009 05:19 AM, Matthias Klose wrote:
> the attached patch enables the link tests on linux, kfreebsd, and hurd
> targets. checked with the (Debian) kfreebsd and hurd maintainers that
> this is the right thing to do (although there doesn't exist an active
> port of these on arm or hppa. tested on i486-linux-gnu,
> arm-linux-gnueabi and hppa-linux-gnu. ok for the trunk?
First, thanks Matthias for your patience on this issue.

The patch looks very nice to me, just wait one day or so for comments
and then go ahead, patch is approved for mainline.

If you want, I would suggest adding a one-line comment in the code, say,
after " # Do link tests if possible, instead asm tests, limited to some
platforms", mentioning the PRs, these thorny issues about libgcc...

Thanks again,
Paolo.

Re: [patch] Fix libffi.call/cls_align_pointer.c on Solaris < 10

2009-12-11T01:44:25Z

Eric Botcazou wrote:

> libffi.call/cls_align_pointer.c fails to compile on Solaris < 10 because
> PRIuPTR is not defined. Hence the attached kludge.
>
> Tested on SPARC/Solaris 9 and SPARC/Solaris 10, OK for mainline?
>
>
> 2009-12-11 Eric Botcazou <ebotcazou@...>
>
> * testsuite/libffi.call/ffitest.h: Define PRIuPTR on Solaris < 10.

Oh, I suppose so.

Andrew.

Re: PATCH: Fix 64-bit libffi testsuite on Solaris 10+ (PR libffi/40700)

2009-12-11T01:43:20Z

Andreas Tobler wrote:

> On 10.12.09 10:52, Andrew Haley wrote:
>> Rainer Orth wrote:
>>> As described in the PR, many 64-bit libffi testcases started to fail on
>>> Solaris 10 and 11 between 20090612 and 20090622. Core dump logging
>>> revealed the cause:
>>>
>>> Nov 27 14:45:24 cumaru genunix: [ID 269049 kern.notice] NOTICE: cls_ushort.exe[21514] attempt to execute non-executable data at 0x600fd0 by uid 2110
>>>
>>> I could track this to the following patch:
>>>
>>> 2009-06-11 Timothy Wall<twall@...>
>>> [...]
>>> * testsuite/libffi.call/closure_fn0.c,
>>> [...]
>>> testsuite/libffi.special/unwindtest.cc: use ffi_closure_alloc instead
>>> of checking for MMAP. Use intptr_t instead of long casts.
>>>
>>> While before the patch, the testsuite would have used allocate_mmap to
>>> allocate ffi_closure's, afterwards src/closures.c (ffi_closure_alloc)
>>> without FFI_MMAP_EXEC_WRIT defined would simply use malloc instead,
>>> leading to the observed failure.
>>>
>>> So the fix is obvious: just define FFI_MMAP_EXEC_WRIT for 64-bit
>>> Solaris/x86. The following patch does just that and allows the libffi
>>> testsuite to complete almost successfully (the remaining failures are
>>> unrelated) for both 32 and 64 bit on i386-pc-solaris2.11.
>>>
>>> Ok for mainline?
>> Yes, thanks.
>>
>> Cc'd to libffi upstream.
>
> I'm late.
>
> Anyway, there are other architectures which do have the same issue.
> FreeBSD, OpenBSD, apple-darwin10. We 'solved' this with adding the
> snippet below in the configure.ac (from the libffi sources, not in the
> gcc repo yet.):
>
> case "$target" in
> *-apple-darwin10* | *-*-freebsd* | *-*-openbsd*)
> AC_DEFINE(FFI_MMAP_EXEC_WRIT, 1,
> [Cannot use malloc on this target, so, we revert to
> alternative means])
> ;;
>
>
> So, my question, shall we move the three remaining OS variants into the
> closures.c file. Or should we move the solaris/x86 part from the
> closures.c file into the configure.ac part?
>
> Both are ok with me, but I think we should have a consistency in this area.

Please do whatever you find the most elegant and consistent: I'm sure we will
trust you to find the sweet spot...

Andrew.

[patch] Fix libffi.call/cls_align_pointer.c on Solaris < 10

2009-12-11T00:48:42Z

Hi,

libffi.call/cls_align_pointer.c fails to compile on Solaris < 10 because
PRIuPTR is not defined. Hence the attached kludge.

Tested on SPARC/Solaris 9 and SPARC/Solaris 10, OK for mainline?

2009-12-11 Eric Botcazou <ebotcazou@...>

* testsuite/libffi.call/ffitest.h: Define PRIuPTR on Solaris < 10.

--
Eric Botcazou

[solaris_libffi.diff]

Index: testsuite/libffi.call/ffitest.h =================================================================== --- testsuite/libffi.call/ffitest.h (revision 155123) +++ testsuite/libffi.call/ffitest.h (working copy) @@ -54,6 +54,15 @@ #define PRIuLL "llu" #endif +/* Solaris < 10 kludge. */ +#if defined(__sun__) && defined(__svr4__) && !defined(PRIuPTR) +#if defined(__arch64__) || defined (__x86_64__) +#define PRIuPTR "lu" +#else +#define PRIuPTR "u" +#endif +#endif + #ifdef USING_MMAP static inline void * allocate_mmap (size_t size)

Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

2009-12-10T20:19:47Z

On 09.12.2009 11:50, Paolo Carlini wrote:
> On 12/09/2009 11:42 AM, Matthias Klose wrote:
>> would a patch acceptable to run these link tests on linux only?
>
> Sure. If you can cook up something (e.g, a version of the configure code
> I wrote at the time) running only where it's safe to run it (I think
> linux targets are all safe), fine with me!

the attached patch enables the link tests on linux, kfreebsd, and hurd targets.
checked with the (Debian) kfreebsd and hurd maintainers that this is the right
thing to do (although there doesn't exist an active port of these on arm or
hppa. tested on i486-linux-gnu, arm-linux-gnueabi and hppa-linux-gnu. ok for the
trunk?

Matthias

libstdc++-v3/
2009-12-09 Paolo Carlini <paolo.carlini@...>
Matthias Klose <doko@...>

PR libstdc++/40133
* acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*,
*-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when possible.
* configure: Regenerate.

Index: libstdc++-v3/acinclude.m4
===================================================================
--- a/src/libstdc++-v3/acinclude.m4 (revision 155104)
+++ b/src/libstdc++-v3/acinclude.m4 (working copy)
@@ -2438,8 +2438,7 @@
dnl that are used should be checked.
dnl
dnl Note:
-dnl libgomp and libgfortran do this with a link test, instead of an asm test.
-dnl see: CHECK_SYNC_FETCH_AND_ADD
+dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD.
dnl
dnl Defines:
dnl _GLIBCXX_ATOMIC_BUILTINS_1
@@ -2451,12 +2450,120 @@
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
old_CXXFLAGS="$CXXFLAGS"
-
+
+ # Do link tests if possible, instead asm tests, limited to some platforms
+ atomic_builtins_link_tests=no
+ if test x$gcc_no_link != xyes; then
+ # Can do link tests. Limit to some tested platforms
+ case "$host" in
+ *-*-linux* | *-*-kfreebsd*-gnu | *-*-gnu*)
+ atomic_builtins_link_tests=yes
+ ;;
+ esac
+ fi
+
+ if test x$atomic_builtins_link_tests = xyes; then
+
+ # Do link tests.
+
+ CXXFLAGS="$CXXFLAGS -fno-exceptions"
+
+ AC_MSG_CHECKING([for atomic builtins for bool])
+ AC_CACHE_VAL(glibcxx_cv_atomic_bool, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef bool atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_bool=yes],
+ [glibcxx_cv_atomic_bool=no])
+ ])
+ if test $glibcxx_cv_atomic_bool = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
+ [Define if builtin atomic operations for bool are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_bool)
+
+ AC_MSG_CHECKING([for atomic builtins for short])
+ AC_CACHE_VAL(glibcxx_cv_atomic_short, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef short atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_short=yes],
+ [glibcxx_cv_atomic_short=no])
+ ])
+ if test $glibcxx_cv_atomic_short = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
+ [Define if builtin atomic operations for short are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_short)
+
+ AC_MSG_CHECKING([for atomic builtins for int])
+ AC_CACHE_VAL(glibcxx_cv_atomic_int, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef int atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_int=yes],
+ [glibcxx_cv_atomic_int=no])
+ ])
+ if test $glibcxx_cv_atomic_int = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
+ [Define if builtin atomic operations for int are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_int)
+
+ AC_MSG_CHECKING([for atomic builtins for long long])
+ AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [
+ AC_TRY_LINK(
+ [ ],
+ [typedef long long atomic_type;
+ atomic_type c1;
+ atomic_type c2;
+ const atomic_type c3(0);
+ __sync_fetch_and_add(&c1, c2);
+ __sync_val_compare_and_swap(&c1, c3, c2);
+ __sync_lock_test_and_set(&c1, c3);
+ __sync_lock_release(&c1);
+ __sync_synchronize();],
+ [glibcxx_cv_atomic_long_long=yes],
+ [glibcxx_cv_atomic_long_long=no])
+ ])
+ if test $glibcxx_cv_atomic_long_long = yes; then
+ AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
+ [Define if builtin atomic operations for long long are supported on this host.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
+
+ else
+
+ # Do asm tests.
+
# Compile unoptimized.
CXXFLAGS='-O0 -S'

- # Fake what AC_TRY_COMPILE does, without linking as this is
- # unnecessary for a builtins test.
+ # Fake what AC_TRY_COMPILE does.

cat > conftest.$ac_ext << EOF
[#]line __oline__ "configure"
@@ -2478,14 +2585,14 @@
AC_MSG_CHECKING([for atomic builtins for bool])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinsb=no
+ glibcxx_cv_atomic_bool=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
[Define if builtin atomic operations for bool are supported on this host.])
- enable_atomic_builtinsb=yes
+ glibcxx_cv_atomic_bool=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinsb)
+ AC_MSG_RESULT($glibcxx_cv_atomic_bool)
rm -f conftest*

cat > conftest.$ac_ext << EOF
@@ -2508,14 +2615,14 @@
AC_MSG_CHECKING([for atomic builtins for short])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinss=no
+ glibcxx_cv_atomic_short=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
[Define if builtin atomic operations for short are supported on this host.])
- enable_atomic_builtinss=yes
+ glibcxx_cv_atomic_short=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinss)
+ AC_MSG_RESULT($glibcxx_cv_atomic_short)
rm -f conftest*

cat > conftest.$ac_ext << EOF
@@ -2539,14 +2646,14 @@
AC_MSG_CHECKING([for atomic builtins for int])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinsi=no
+ glibcxx_cv_atomic_int=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
[Define if builtin atomic operations for int are supported on this host.])
- enable_atomic_builtinsi=yes
+ glibcxx_cv_atomic_int=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinsi)
+ AC_MSG_RESULT($glibcxx_cv_atomic_int)
rm -f conftest*

cat > conftest.$ac_ext << EOF
@@ -2569,22 +2676,23 @@
AC_MSG_CHECKING([for atomic builtins for long long])
if AC_TRY_EVAL(ac_compile); then
if grep __sync_ conftest.s >/dev/null 2>&1 ; then
- enable_atomic_builtinsll=no
+ glibcxx_cv_atomic_long_long=no
else
AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
[Define if builtin atomic operations for long long are supported on this host.])
- enable_atomic_builtinsll=yes
+ glibcxx_cv_atomic_long_long=yes
fi
fi
- AC_MSG_RESULT($enable_atomic_builtinsll)
+ AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
rm -f conftest*

+ fi

CXXFLAGS="$old_CXXFLAGS"
AC_LANG_RESTORE

# Set atomicity_dir to builtins if either of above tests pass.
- if test $enable_atomic_builtinsi = yes || test $enable_atomic_builtinsb = yes ; then
+ if test $glibcxx_cv_atomic_int = yes || test $glibcxx_cv_atomic_bool = yes ; then
atomicity_dir=cpu/generic/atomicity_builtins
fi

Re: PATCH: Fix 64-bit libffi testsuite on Solaris 10+ (PR libffi/40700)

2009-12-10T14:06:38Z

On 10.12.09 10:52, Andrew Haley wrote:

> Rainer Orth wrote:
>> As described in the PR, many 64-bit libffi testcases started to fail on
>> Solaris 10 and 11 between 20090612 and 20090622. Core dump logging
>> revealed the cause:
>>
>> Nov 27 14:45:24 cumaru genunix: [ID 269049 kern.notice] NOTICE: cls_ushort.exe[21514] attempt to execute non-executable data at 0x600fd0 by uid 2110
>>
>> I could track this to the following patch:
>>
>> 2009-06-11 Timothy Wall<twall@...>
>> [...]
>> * testsuite/libffi.call/closure_fn0.c,
>> [...]
>> testsuite/libffi.special/unwindtest.cc: use ffi_closure_alloc instead
>> of checking for MMAP. Use intptr_t instead of long casts.
>>
>> While before the patch, the testsuite would have used allocate_mmap to
>> allocate ffi_closure's, afterwards src/closures.c (ffi_closure_alloc)
>> without FFI_MMAP_EXEC_WRIT defined would simply use malloc instead,
>> leading to the observed failure.
>>
>> So the fix is obvious: just define FFI_MMAP_EXEC_WRIT for 64-bit
>> Solaris/x86. The following patch does just that and allows the libffi
>> testsuite to complete almost successfully (the remaining failures are
>> unrelated) for both 32 and 64 bit on i386-pc-solaris2.11.
>>
>> Ok for mainline?
>
> Yes, thanks.
>
> Cc'd to libffi upstream.

I'm late.

Anyway, there are other architectures which do have the same issue.
FreeBSD, OpenBSD, apple-darwin10. We 'solved' this with adding the
snippet below in the configure.ac (from the libffi sources, not in the
gcc repo yet.):

case "$target" in
*-apple-darwin10* | *-*-freebsd* | *-*-openbsd*)
AC_DEFINE(FFI_MMAP_EXEC_WRIT, 1,
[Cannot use malloc on this target, so, we revert to
alternative means])
;;

So, my question, shall we move the three remaining OS variants into the
closures.c file. Or should we move the solaris/x86 part from the
closures.c file into the configure.ac part?

Both are ok with me, but I think we should have a consistency in this area.

Andreas

Re: PATCH: Fix 64-bit libffi testsuite on Solaris 10+ (PR libffi/40700)

2009-12-10T01:52:20Z

Rainer Orth wrote:

> As described in the PR, many 64-bit libffi testcases started to fail on
> Solaris 10 and 11 between 20090612 and 20090622. Core dump logging
> revealed the cause:
>
> Nov 27 14:45:24 cumaru genunix: [ID 269049 kern.notice] NOTICE: cls_ushort.exe[21514] attempt to execute non-executable data at 0x600fd0 by uid 2110
>
> I could track this to the following patch:
>
> 2009-06-11 Timothy Wall <twall@...>
> [...]
> * testsuite/libffi.call/closure_fn0.c,
> [...]
> testsuite/libffi.special/unwindtest.cc: use ffi_closure_alloc instead
> of checking for MMAP. Use intptr_t instead of long casts.
>
> While before the patch, the testsuite would have used allocate_mmap to
> allocate ffi_closure's, afterwards src/closures.c (ffi_closure_alloc)
> without FFI_MMAP_EXEC_WRIT defined would simply use malloc instead,
> leading to the observed failure.
>
> So the fix is obvious: just define FFI_MMAP_EXEC_WRIT for 64-bit
> Solaris/x86. The following patch does just that and allows the libffi
> testsuite to complete almost successfully (the remaining failures are
> unrelated) for both 32 and 64 bit on i386-pc-solaris2.11.
>
> Ok for mainline?

Yes, thanks.

Cc'd to libffi upstream.

Andrew.

PATCH: Fix 64-bit libffi testsuite on Solaris 10+ (PR libffi/40700)

2009-12-09T17:44:00Z

As described in the PR, many 64-bit libffi testcases started to fail on
Solaris 10 and 11 between 20090612 and 20090622. Core dump logging
revealed the cause:

Nov 27 14:45:24 cumaru genunix: [ID 269049 kern.notice] NOTICE: cls_ushort.exe[21514] attempt to execute non-executable data at 0x600fd0 by uid 2110

I could track this to the following patch:

2009-06-11 Timothy Wall <twall@...>
[...]
* testsuite/libffi.call/closure_fn0.c,
[...]
testsuite/libffi.special/unwindtest.cc: use ffi_closure_alloc instead
of checking for MMAP. Use intptr_t instead of long casts.

While before the patch, the testsuite would have used allocate_mmap to
allocate ffi_closure's, afterwards src/closures.c (ffi_closure_alloc)
without FFI_MMAP_EXEC_WRIT defined would simply use malloc instead,
leading to the observed failure.

So the fix is obvious: just define FFI_MMAP_EXEC_WRIT for 64-bit
Solaris/x86. The following patch does just that and allows the libffi
testsuite to complete almost successfully (the remaining failures are
unrelated) for both 32 and 64 bit on i386-pc-solaris2.11.

Ok for mainline?

Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

2009-12-10 Rainer Orth <ro@...>

PR libffi/40700
* src/closures.c [X86_64 && __sun__ && __svr4__]
(FFI_MMAP_EXEC_WRIT): Define.

Index: libffi/src/closures.c
===================================================================
--- libffi/src/closures.c (revision 155092)
+++ libffi/src/closures.c (working copy)
@@ -1,6 +1,6 @@
/* -----------------------------------------------------------------------
closures.c - Copyright (c) 2007 Red Hat, Inc.
- Copyright (C) 2007 Free Software Foundation, Inc
+ Copyright (C) 2007, 2009 Free Software Foundation, Inc

Code to allocate and deallocate memory for closures.

@@ -50,6 +50,11 @@
executable memory. */
# define FFI_MMAP_EXEC_WRIT 1
# endif
+# if defined(X86_64) && defined(__sun__) && defined(__svr4__)
+/* The data segment on 64-bit Solaris/x86 isn't executable, so use mmap
+ instead. */
+# define FFI_MMAP_EXEC_WRIT 1
+# endif
#endif

#if FFI_MMAP_EXEC_WRIT && !defined FFI_MMAP_EXEC_SELINUX

FYI Patch: java/41991: Use -allow_stack_execute on Darwin

2009-12-09T10:55:03Z

On Sat, Dec 5, 2009 at 6:54 AM, Jack Howarth <howarth@...> wrote:

> Bryce,
> Your patch eliminates the crashes in gcj completely for gcc trunk
> on x86_64-apple-darwin9 if I also regress out r154282 and r154283
> so that the FSF libgcc's unwinder is used again. So we are starting
> to peel the layers off of the problem. Your patch definitely should
> go into gcc trunk and gcc 4.4 branch (where it will be immediately
> useful on darwin9 since the libgcc_ext changes don't exist there).

Thanks for testing, Jack. I have checked this patch in to both trunk
and 4.4 branch.

2009-12-09 Bryce McKinlay <bmckinlay@...>

PR java/41991
* configure.ac (SYSTEMSPEC): Pass -allow_stack_execute to Darwin
linker.
* Makefile.am (gij_LDFLAGS): Remove extra_gij_ldflags.
* configure: Regenerate.
* Makefile.in: Regenerate.

Bryce

libjava-darwin-stack.patch (7K) Download Attachment

Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

2009-12-09T02:50:07Z

On 12/09/2009 11:42 AM, Matthias Klose wrote:
> would a patch acceptable to run these link tests on linux only?

Sure. If you can cook up something (e.g, a version of the configure code
I wrote at the time) running only where it's safe to run it (I think
linux targets are all safe), fine with me!

Paolo.

Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

2009-12-09T02:46:27Z

On 12/09/2009 11:42 AM, Matthias Klose wrote:
> would a patch acceptable to run these link tests on linux only?
Sure. If you can cook up something running only where it's safe to run
it (I think linux targets are all safe), fine with me!

Paolo.

Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

2009-12-09T02:42:30Z

On 12.11.2009 19:32, Paolo Carlini wrote:
> Matthias Klose wrote:
>> In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote
>> that this scheme requires fixing libtool; I never got feedback from
>> the libtool maintainers. In
>> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00592.html Jakub and
>> Alexandre did "agree that the linker script for targets that need it
>> is probably easier".
> I'm still not convinced that all the targets possibly affected have been
> dealt with.

I addressed linux targets having a Debian port is available. sh/sh4 should be
fine as it did link with -lgcc_s -lgcc before. Didn't check m68k-linux.

> But, I don't consider myself knowledgeable enough in this
> area, I'd like to see some comments from, eg, Jakub and Joseph, before
> going ahead with the libstdc++ changes for 40133.
>>> In other
>>> terms, 40134 still blocks 40133, and we cannot fix the latter until the
>>> former is really fully fixed for *all* the affected targets. By the way,
>>> that's why, sorry, I disregarded your ping in the first place, I was
>>> pretty sure it wasn't time yet...
>> So it looks like 40134 is fixed at least for all *-linux targets (I
>> accidentally dropped the patch for parisc, now testing again). How to
>> proceed with this for linux targets?
> In your original message you mentioned sparc too. Is it now fine?

no, sparc-linux was not affected, parisc was, which is now fixed on trunk.

> Anyway, the configure changes I prepared for 40133 aren't linux-specific
> would run anywhere, as I said above I'd like to be reassured by Joseph
> and/or Jakub that such kind of test is now safe to use everywhere as far
> as the compiler proper bits are concerned.

would a patch acceptable to run these link tests on linux only?

Matthias

RE: [patch] use of atomic builtins for arm-linux-eabi in boehm-gc

2009-12-09T02:16:33Z

> Current trunk fails to build on arm-linux-gnueabi in boehm-gc, when
> configured
> --with-mode=thumb:
>
> /tmp/ccVpqOWm.s: Assembler messages:
> /tmp/ccVpqOWm.s:1160: Error: selected processor does not support `swp
> r3,r3,[r2]'
> /tmp/ccVpqOWm.s:2472: Error: selected processor does not support `swp
> r3,r3,[r2]'
> /tmp/ccVpqOWm.s:3232: Error: selected processor does not support `swp
> r3,r3,[r2]'
> make[5]: *** [alloc.lo] Error 1
>
> arm-linux-gnueabi now provides the atomic builtins; use them
> unconditionally (as
> libjava does).
>
> Ok for the trunk, if testing succeeds? The build on trunk configured
> with
> --with-mode=thumb fails for other reasons (PR42093), currently testing
> the patch
> for the 4.4 branch.

2009-12-09 Matthias Klose <doko@...>

* include/private/gc_locks.h: For __ARM_EABI__ define
GC_test_and_set GC_clear to use the atomic builtins.

OK for trunk once testing is complete.

Please also notify the upstream maintainer of boehm-gc, or this patch may
get lost in a future merge.

R.

[patch] use of atomic builtins for arm-linux-eabi in boehm-gc

2009-12-09T02:01:23Z

Current trunk fails to build on arm-linux-gnueabi in boehm-gc, when configured
--with-mode=thumb:

/tmp/ccVpqOWm.s: Assembler messages:
/tmp/ccVpqOWm.s:1160: Error: selected processor does not support `swp r3,r3,[r2]'
/tmp/ccVpqOWm.s:2472: Error: selected processor does not support `swp r3,r3,[r2]'
/tmp/ccVpqOWm.s:3232: Error: selected processor does not support `swp r3,r3,[r2]'
make[5]: *** [alloc.lo] Error 1

arm-linux-gnueabi now provides the atomic builtins; use them unconditionally (as
libjava does).

Ok for the trunk, if testing succeeds? The build on trunk configured with
--with-mode=thumb fails for other reasons (PR42093), currently testing the patch
for the 4.4 branch.

Matthias

2009-12-09 Matthias Klose <doko@...>

* include/private/gc_locks.h: For __ARM_EABI__ define
GC_test_and_set GC_clear to use the atomic builtins.

Index: boehm-gc/include/private/gc_locks.h
===================================================================
--- boehm-gc/include/private/gc_locks.h (revision 155104)
+++ boehm-gc/include/private/gc_locks.h (working copy)
@@ -207,6 +207,12 @@
# define GC_CLEAR_DEFINED
# endif /* ALPHA */
# ifdef ARM32
+# define GC_TEST_AND_SET_DEFINED
+# if (__GNUC__>4)||((__GNUC__==4)&&(__GNUC_MINOR__>=5)) && defined(__ARM_EABI__)
+# define GC_CLEAR_DEFINED
+# define GC_test_and_set(addr) __sync_lock_test_and_set (addr, 1)
+# define GC_clear(addr) __sync_lock_release (addr)
+# else
inline static int GC_test_and_set(volatile unsigned int *addr) {
int oldval;
/* SWP on ARM is very similar to XCHG on x86. Doesn't lock the
@@ -219,7 +225,7 @@
: "memory");
return oldval;
}
-# define GC_TEST_AND_SET_DEFINED
+# endif
# endif /* ARM32 */
# ifdef CRIS
inline static int GC_test_and_set(volatile unsigned int *addr) {

Re: [PATCH] libffi: Remove XFAIL for MIPS from several testcases.

2009-12-08T13:48:57Z

David Daney wrote:
> These six libffi test cases no longer fail.
>
> See:
> http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00762.html
> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01859.html
>
> Tested on mips64-unknown-linux-gnu.
>
> OK to commit?

Ok.

Thank you David!

Andreas

> 2009-12-08 David Daney <ddaney@...>
>
> * testsuite/libffi.call/stret_medium.c: Remove xfail for mips*-*-*
> * testsuite/libffi.call/cls_align_longdouble_split2.c: Same.
> * testsuite/libffi.call/stret_large.c: Same.
> * testsuite/libffi.call/cls_align_longdouble_split.c: Same.
> * testsuite/libffi.call/stret_large2.c: Same.
> * testsuite/libffi.call/stret_medium2.c: Same.
>

Re: [PATCH] libffi: Remove XFAIL for MIPS from several testcases.

2009-12-08T13:46:54Z

On Tue, 2009-12-08 at 12:48 -0800, David Daney wrote:

> These six libffi test cases no longer fail.
>
> See:
> http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00762.html
> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01859.html
>
> Tested on mips64-unknown-linux-gnu.
>
> OK to commit?
>
> 2009-12-08 David Daney <ddaney@...>
>
> * testsuite/libffi.call/stret_medium.c: Remove xfail for mips*-*-*
> * testsuite/libffi.call/cls_align_longdouble_split2.c: Same.
> * testsuite/libffi.call/stret_large.c: Same.
> * testsuite/libffi.call/cls_align_longdouble_split.c: Same.
> * testsuite/libffi.call/stret_large2.c: Same.
> * testsuite/libffi.call/stret_medium2.c: Same.

OK.

Janis

[PATCH] libffi: Remove XFAIL for MIPS from several testcases.

2009-12-08T12:48:46Z

These six libffi test cases no longer fail.

See:
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00762.html
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01859.html

Tested on mips64-unknown-linux-gnu.

OK to commit?

2009-12-08 David Daney <ddaney@...>

* testsuite/libffi.call/stret_medium.c: Remove xfail for mips*-*-*
* testsuite/libffi.call/cls_align_longdouble_split2.c: Same.
* testsuite/libffi.call/stret_large.c: Same.
* testsuite/libffi.call/cls_align_longdouble_split.c: Same.
* testsuite/libffi.call/stret_large2.c: Same.
* testsuite/libffi.call/stret_medium2.c: Same.

Index: libffi/testsuite/libffi.call/stret_medium.c
===================================================================
--- libffi/testsuite/libffi.call/stret_medium.c (revision 154987)
+++ libffi/testsuite/libffi.call/stret_medium.c (working copy)
@@ -6,7 +6,7 @@
PR: none.
Originator: Blake Chaffin 6/21/2007 */

-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-* } } */
+/* { dg-do run { xfail arm*-*-* strongarm*-*-* xscale*-*-* } } */
#include "ffitest.h"

typedef struct struct_72byte {
Index: libffi/testsuite/libffi.call/cls_align_longdouble_split2.c
===================================================================
--- libffi/testsuite/libffi.call/cls_align_longdouble_split2.c (revision 154987)
+++ libffi/testsuite/libffi.call/cls_align_longdouble_split2.c (working copy)
@@ -6,7 +6,7 @@
*/

/* { dg-excess-errors "no long double format" { xfail x86_64-*-mingw* x86_64-*-cygwin* } } */
-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* } } */
+/* { dg-do run { xfail arm*-*-* strongarm*-*-* } } */
/* { dg-options -mlong-double-128 { target powerpc64*-*-* } } */
/* { dg-output "" { xfail x86_64-*-mingw* x86_64-*-cygwin* } } */

Index: libffi/testsuite/libffi.call/stret_large.c
===================================================================
--- libffi/testsuite/libffi.call/stret_large.c (revision 154987)
+++ libffi/testsuite/libffi.call/stret_large.c (working copy)
@@ -6,7 +6,7 @@
PR: none.
Originator: Blake Chaffin 6/21/2007 */

-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-* } } */
+/* { dg-do run { xfail arm*-*-* strongarm*-*-* xscale*-*-* } } */
#include "ffitest.h"

// 13 FPRs: 104 bytes
Index: libffi/testsuite/libffi.call/cls_align_longdouble_split.c
===================================================================
--- libffi/testsuite/libffi.call/cls_align_longdouble_split.c (revision 154987)
+++ libffi/testsuite/libffi.call/cls_align_longdouble_split.c (working copy)
@@ -5,7 +5,7 @@
Originator: <hos@...> 20031203 */

/* { dg-excess-errors "no long double format" { xfail x86_64-*-mingw* x86_64-*-cygwin* } } */
-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-* } } */
+/* { dg-do run { xfail arm*-*-* strongarm*-*-* xscale*-*-* } } */
/* { dg-options -mlong-double-128 { target powerpc64*-*-* } } */
/* { dg-output "" { xfail x86_64-*-mingw* x86_64-*-cygwin* } } */

Index: libffi/testsuite/libffi.call/stret_large2.c
===================================================================
--- libffi/testsuite/libffi.call/stret_large2.c (revision 154987)
+++ libffi/testsuite/libffi.call/stret_large2.c (working copy)
@@ -6,7 +6,7 @@
PR: none.
Originator: Blake Chaffin 6/21/2007 */

-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-* } } */
+/* { dg-do run { xfail arm*-*-* strongarm*-*-* xscale*-*-* } } */
#include "ffitest.h"

// 13 FPRs: 104 bytes
Index: libffi/testsuite/libffi.call/stret_medium2.c
===================================================================
--- libffi/testsuite/libffi.call/stret_medium2.c (revision 154987)
+++ libffi/testsuite/libffi.call/stret_medium2.c (working copy)
@@ -6,7 +6,7 @@
PR: none.
Originator: Blake Chaffin 6/21/2007 */

-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-* } } */
+/* { dg-do run { xfail arm*-*-* strongarm*-*-* xscale*-*-* } } */
#include "ffitest.h"

typedef struct struct_72byte {

Re: Fix -findirect-dispatch Java failures on SPARC/Linux

2009-12-07T15:34:48Z

> 2009-12-06 Eric Botcazou <ebotcazou@...>
>
> * config/sparc/linux.h (ASM_SPEC): Pass -K PIC if -findirect-dispatch.
> * config/sparc/linux64.h (ASM_SPEC): Likewise.

Applied. I'll apply
http://gcc.gnu.org/ml/java-patches/2009-q4/msg00025.html
tomorrow barring any objections.

--
Eric Botcazou

Re: Fix -findirect-dispatch Java failures on SPARC/Linux

2009-12-07T01:26:34Z

Richard Henderson wrote:

> On 12/06/2009 11:08 AM, Andrew Haley wrote:
>> Eric Botcazou wrote:
>>> The problem is
>>>
>>> LIBGCJ_BC_SPEC="%{findirect-dispatch:-fPIC}"
>>>
>>> but you cannot compile with -fPIC without assembling with -K PIC on the SPARC.
>>>
>>> Hence the attached kludge, which yields:
>>>
>>> Native configuration is sparc-unknown-linux-gnu
>> I don't get it. Surely this means that -fpic is broken on
>> SPARC/Linux everywhere.
>
> No, there's an ASM_SPEC that adds -K PIC in response to -fPIC on the
> command-line. But the libgcj_bc_spec doesn't add the -fPIC to the
> compiler command-line, but to the jc1 command line, so the ASM_SPEC
> pattern doesn't trigger.

Oh, I see. Thanks.

Andrew.

Re: [patch] Fix configure glitch on Solaris

2009-12-07T01:25:43Z

Eric Botcazou wrote:

> Hi,
>
> natVMNetworkInterfacePosix.cc fails to compile under Solaris because 'struct
> ifconf' is not defined because net/if.h is not included, the root problem
> being that net/if.h requires sys/socket.h and the configure machinery doesn't
> provide it.
>
> Hence the attached patch, tested on SPARC/Solaris 9 and AMD64/Linux. OK for
> mainline?
>
>
> 2009-12-06 Eric Botcazou <ebotcazou@...>
>
> * configure.ac (net/if.h check): Include sys/socket.h if present.
> * configure: Regenerate.

Sure.

Thanks,
Andrew.

Re: Fix -findirect-dispatch Java failures on SPARC/Linux

2009-12-06T13:27:28Z

On 12/06/2009 11:08 AM, Andrew Haley wrote:

> Eric Botcazou wrote:
>> The problem is
>>
>> LIBGCJ_BC_SPEC="%{findirect-dispatch:-fPIC}"
>>
>> but you cannot compile with -fPIC without assembling with -K PIC on the SPARC.
>>
>> Hence the attached kludge, which yields:
>>
>> Native configuration is sparc-unknown-linux-gnu
>
> I don't get it. Surely this means that -fpic is broken on
> SPARC/Linux everywhere.

No, there's an ASM_SPEC that adds -K PIC in response to -fPIC on the
command-line. But the libgcj_bc_spec doesn't add the -fPIC to the
compiler command-line, but to the jc1 command line, so the ASM_SPEC
pattern doesn't trigger.

r~

Re: Fix -findirect-dispatch Java failures on SPARC/Linux

2009-12-06T11:08:22Z

Eric Botcazou wrote:
> The problem is
>
> LIBGCJ_BC_SPEC="%{findirect-dispatch:-fPIC}"
>
> but you cannot compile with -fPIC without assembling with -K PIC on the SPARC.
>
> Hence the attached kludge, which yields:
>
> Native configuration is sparc-unknown-linux-gnu

I don't get it. Surely this means that -fpic is broken on
SPARC/Linux everywhere.

Andrew.

[patch] Fix configure glitch on Solaris

2009-12-06T07:46:29Z

Hi,

natVMNetworkInterfacePosix.cc fails to compile under Solaris because 'struct
ifconf' is not defined because net/if.h is not included, the root problem
being that net/if.h requires sys/socket.h and the configure machinery doesn't
provide it.

Hence the attached patch, tested on SPARC/Solaris 9 and AMD64/Linux. OK for
mainline?

2009-12-06 Eric Botcazou <ebotcazou@...>

* configure.ac (net/if.h check): Include sys/socket.h if present.
* configure: Regenerate.

--
Eric Botcazou

[solaris_libjava.diff]

Index: configure.ac =================================================================== --- configure.ac (revision 155009) +++ configure.ac (working copy) @@ -1568,9 +1568,17 @@ TL_AC_GXX_INCLUDE_DIR # for now. If you change this, you also must update natFile.cc. AC_CHECK_HEADERS([unistd.h bstring.h sys/time.h sys/types.h fcntl.h \ sys/ioctl.h sys/filio.h sys/stat.h sys/select.h \ - sys/socket.h netinet/in.h arpa/inet.h netdb.h net/if.h \ + sys/socket.h netinet/in.h arpa/inet.h netdb.h \ pwd.h sys/config.h stdint.h langinfo.h locale.h \ dirent.h sys/rw_lock.h magic.h ifaddrs.h]) + +# sys/socket.h is a prerequisite for net/if.h on Solaris. +AC_CHECK_HEADERS(net/if.h, [], [], [ +#ifdef HAVE_SYS_SOCKET_H +#include <sys/socket.h> +#endif +]) + AC_CHECK_HEADERS(inttypes.h, [ AC_DEFINE(HAVE_INTTYPES_H, 1, [Define if <inttypes.h> is available]) AC_DEFINE(JV_HAVE_INTTYPES_H, 1, [Define if <inttypes.h> is available])

Fix -findirect-dispatch Java failures on SPARC/Linux

2009-12-06T07:36:25Z

The problem is

LIBGCJ_BC_SPEC="%{findirect-dispatch:-fPIC}"

but you cannot compile with -fPIC without assembling with -K PIC on the SPARC.

Hence the attached kludge, which yields:

Native configuration is sparc-unknown-linux-gnu

=== libjava tests ===

Running target unix

=== libjava Summary ===

# of expected passes 2574

Does anyone have a better idea?

2009-12-06 Eric Botcazou <ebotcazou@...>

* config/sparc/linux.h (ASM_SPEC): Pass -K PIC if -findirect-dispatch.
* config/sparc/linux64.h (ASM_SPEC): Likewise.

--
Eric Botcazou

[sparc_specs.diff]

Index: config/sparc/linux.h =================================================================== --- config/sparc/linux.h (revision 155009) +++ config/sparc/linux.h (working copy) @@ -98,9 +98,17 @@ along with GCC; see the file COPYING3. /* The sun bundled assembler doesn't accept -Yd, (and neither does gas). It's safe to pass -s always, even if -g is not used. */ #undef ASM_SPEC -#define ASM_SPEC \ - "%{V} %{v:%{!V:-V}} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Wa,*:%*} -s \ - %{fpic|fPIC|fpie|fPIE:-K PIC} %(asm_cpu) %(asm_relax)" +#define ASM_SPEC "\ +%{V} \ +%{v:%{!V:-V}} \ +%{!Qn:-Qy} \ +%{n} \ +%{T} \ +%{Ym,*} \ +%{Wa,*:%*} \ +-s \ +%{fpic|fPIC|fpie|fPIE|findirect-dispatch:-K PIC} \ +%(asm_cpu) %(asm_relax)" #undef ASM_OUTPUT_ALIGNED_LOCAL #define ASM_OUTPUT_ALIGNED_LOCAL(FILE, NAME, SIZE, ALIGN) \ Index: config/sparc/linux64.h =================================================================== --- config/sparc/linux64.h (revision 155009) +++ config/sparc/linux64.h (working copy) @@ -235,7 +235,8 @@ along with GCC; see the file COPYING3. %{T} \ %{Ym,*} \ %{Wa,*:%*} \ --s %{fpic|fPIC|fpie|fPIE:-K PIC} \ +-s \ +%{fpic|fPIC|fpie|fPIE|findirect-dispatch:-K PIC} \ %{mlittle-endian:-EL} \ %(asm_cpu) %(asm_arch) %(asm_relax)"

[patch] Some SPARC housekeeping work

2009-12-05T15:16:53Z

Hi,

on the heels of the changes recently made to the GCC unwinder on the SPARC:

2009-11-12 Eric Botcazou <ebotcazou@...>
Laurent GUERBY <laurent@...>

* config/sparc/linux-unwind.h (sparc64_fallback_frame_state): Tidy.
Do not schedule an %sp restore. Compensate for RETURN_ADDR_OFFSET.
(sparc_fallback_frame_state): Tidy. Compensate for RETURN_ADDR_OFFSET.

2009-10-11 Jose Ruiz <ruiz@...>
Eric Botcazou <ebotcazou@...>

PR target/33743
* config/sparc/sol2.h (MD_UNWIND_SUPPORT): Define.
* config/sparc/sol2-unwind.h: New file.

libgcj needs to be slightly adjusted. Built and tested on SPARC/Solaris 9 and
SPARC/Linux, OK for mainline?

[The testsuite is clean on both platforms, except that all test fails on Linux
with -findirect-dispatch, a SIGSEGV in _Jv_global_static_constructor. Does
that ring a bell to anyone?]

2009-12-05 Eric Botcazou <ebotcazou@...>

* configure.host (sparc*-sun-solaris2.*): New case.
* include/dwarf2-signal.h (MAKE_THROW_FRAME, SPARC case): Make dummy.
* include/sparc-signal.h: Do not include ucontext.h.
(SIGNAL_HANDLER): Rename symbol.
(FLUSH_REGISTER_WINDOWS): Delete.
(MAKE_THROW_FRAME): Make dummy.
(INIT_SEGV): Adjust for above renaming.
(INIT_FPE): Likewise.

--
Eric Botcazou

[sparc_libjava.diff]

Index: configure.host =================================================================== --- configure.host (revision 155009) +++ configure.host (working copy) @@ -340,6 +340,10 @@ EOF can_unwind_signal=yes DIVIDESPEC=-fuse-divide-subroutine ;; + sparc*-sun-solaris2.*) + slow_pthread_self= + can_unwind_signal=yes + ;; esac case "${host}" in Index: include/dwarf2-signal.h =================================================================== --- include/dwarf2-signal.h (revision 155009) +++ include/dwarf2-signal.h (working copy) @@ -1,6 +1,6 @@ // dwarf2-signal.h - Catch runtime signals and turn them into exceptions. -/* Copyright (C) 2000, 2001 Free Software Foundation +/* Copyright (C) 2000, 2001, 2009 Free Software Foundation This file is part of libgcj. @@ -58,61 +58,7 @@ do \ _sc->sc_ip++; \ } \ while (0) -#elif defined(__sparc__) -/* We could do the unwind of the signal frame quickly by hand here like - sparc-signal.h does under Solaris, but that makes debugging unwind - failures almost impossible. */ -#if !defined(__arch64__) -#define MAKE_THROW_FRAME(_exception) \ -do \ -{ \ - /* Sparc-32 leaves PC pointing at a faulting instruction \ - always. \ - We advance the PC one instruction past the exception causing PC. \ - This is done because FDEs are found with "context->ra - 1" in the \ - unwinder. \ - Also, the dwarf2 unwind machinery is going to add 8 to the \ - PC it uses on Sparc. So we adjust the PC here. We do it here \ - because we run once for such an exception, however the Sparc specific\ - unwind can run multiple times for the same exception and it would \ - adjust the PC more than once resulting in a bogus value. */ \ - struct sig_regs { \ - unsigned int psr, pc, npc, y, u_regs[16]; \ - } *regp; \ - unsigned int insn; \ - __asm__ __volatile__("ld [%%i7 + 8], %0" : "=r" (insn)); \ - /* mov __NR_sigaction, %g1; Old signal stack layout */ \ - if (insn == 0x821020d8) \ - regp = (struct sig_regs *) _sip; \ - else \ - /* mov __NR_rt_sigaction, %g1; New signal stack layout */ \ - regp = (struct sig_regs *) (_sip + 1); \ - regp->pc = ((regp->pc + 4) - 8); \ -} \ -while (0) -#else -#define MAKE_THROW_FRAME(_exception) \ -do \ -{ \ - /* Sparc-64 leaves PC pointing at a faulting instruction \ - always. \ - We advance the PC one instruction past the exception causing PC. \ - This is done because FDEs are found with "context->ra - 1" in the \ - unwinder. \ - Also, the dwarf2 unwind machinery is going to add 8 to the \ - PC it uses on Sparc. So we adjust the PC here. We do it here \ - because we run once for such an exception, however the Sparc specific\ - unwind can run multiple times for the same exception and it would \ - adjust the PC more than once resulting in a bogus value. */ \ - struct pt_regs { \ - unsigned long u_regs[16]; \ - unsigned long tstate, tpc, tnpc; \ - unsigned int y, fprs; \ - } *regp = (struct pt_regs *) (_sip + 1); \ - regp->tpc = ((regp->tpc + 4) - 8); \ -} \ -while (0) -#endif + #else #define MAKE_THROW_FRAME(_exception) \ do \ Index: include/sparc-signal.h =================================================================== --- include/sparc-signal.h (revision 155009) +++ include/sparc-signal.h (working copy) @@ -1,6 +1,6 @@ // sparc-signal.h - Catch runtime signals and turn them into exceptions. -/* Copyright (C) 1998, 1999, 2000 Free Software Foundation +/* Copyright (C) 1998, 1999, 2000, 2009 Free Software Foundation This file is part of libgcj. @@ -12,43 +12,22 @@ details. */ #define JAVA_SIGNAL_H 1 #include <signal.h> -#include <ucontext.h> #define HANDLE_SEGV 1 #define HANDLE_FPE 1 -#define SIGNAL_HANDLER(_name) \ -static void _name (int _dummy __attribute__ ((__unused__)), \ - siginfo_t *_info __attribute__ ((__unused__)), \ - void *arg __attribute__ ((__unused__))) - -#ifdef __arch64__ -#define FLUSH_REGISTER_WINDOWS \ - asm volatile ("flushw"); -#else -#define FLUSH_REGISTER_WINDOWS \ - asm volatile ("ta 3"); -#endif +#define SIGNAL_HANDLER(_name) \ +static void _Jv_##_name (int, \ + siginfo_t *_si __attribute__ ((__unused__)), \ + void *_uc __attribute__ ((__unused__))) -#define MAKE_THROW_FRAME(_exception) \ -do \ -{ \ - ucontext_t *_context = (ucontext_t *) arg; \ - (void)_dummy; \ - (void)_info; \ - register long sp = _context->uc_mcontext.gregs[REG_SP]; \ - register long retaddr = _context->uc_mcontext.gregs[REG_O7]; \ - FLUSH_REGISTER_WINDOWS; \ - asm volatile ("mov %0, %%i6; mov %1, %%i7" \ - : : "r"(sp), "r"(retaddr)); \ -} \ -while (0) +#define MAKE_THROW_FRAME(_exception) #define INIT_SEGV \ do \ { \ struct sigaction act; \ - act.sa_sigaction = catch_segv; \ + act.sa_sigaction = _Jv_catch_segv; \ act.sa_flags = SA_SIGINFO | SA_NODEFER; \ sigemptyset (&act.sa_mask); \ sigaction (SIGSEGV, &act, NULL); \ @@ -59,8 +38,8 @@ while (0) do \ { \ struct sigaction act; \ + act.sa_sigaction = _Jv_catch_fpe; \ act.sa_flags = SA_SIGINFO | SA_NODEFER; \ - act.sa_sigaction = catch_fpe; \ sigemptyset (&act.sa_mask); \ sigaction (SIGFPE, &act, NULL); \ } \

Re: [PATCH] Backport two ltdl fixes to fix CVE-2009-3736

2009-12-05T09:20:04Z

Hello Jakub,

* Jakub Jelinek wrote on Thu, Dec 03, 2009 at 10:11:50AM CET:

> libgcj System.loadLibrary which uses lt_dlopen{,ext} under the hood
> tries to open even files in the current directory. When running
> a Java program from an untrusted directory (such as /tmp), someone might
> put there a rogue *.la or *.so file and let libgcj dlopen it instead of
> the library it was supposed to load. Additionally, while e.g. libtool.m4
> in gcc 4.4/4.5 is correct, acinclude.m4 in libjava/libltdl hasn't been
> regenerated and so the hardcoded search path to libraries could include
> stuff like ...:hwcap:0:nosegneg:... and search hwcap/, 0/ and nosegneg/
> subdirs of the current directory for *.la files and *.so libraries.
>
> Fixed thusly, bootstrapped/regtested on {x86_64,i686,powerpc{,64}}-linux.
> Ok for 4.4/4.3? The trunk I'll leave for Ralf's 2.2.6b backport instead.

I think you should apply this patch to trunk as well. libjava/libltdl
does not pick up the changes from the toplevel Libtool files. I wonder
whether that is a bug in itself; OTOH, I remember there have been
problems in the past with trying to get old libltdl to work with newer
Libtool macro files.

Thanks,
Ralf

> 2009-12-03 Jakub Jelinek <jakub@...>
>
> * acinclude.m4: Regenerated to pick:
> 2007-06-22 Ralf Wildenhues <Ralf.Wildenhues@...>
> * libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]:
> Ignore lines in ld.so.conf starting with 'hwcap '.
>
> * configure: Regenerated.
>
> 2009-11-24 Peter O'Gorman <peter@...>
>
> Backport of libltdl changes from the 2.26b release.
> * ltdl.c: Backport changes.

Re: [PATCH] Backport two ltdl fixes to fix CVE-2009-3736

2009-12-03T09:19:21Z

On 12/03/2009 01:11 AM, Jakub Jelinek wrote:
> * acinclude.m4: Regenerated to pick:
> 2007-06-22 Ralf Wildenhues<Ralf.Wildenhues@...>
> * libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]:
> Ignore lines in ld.so.conf starting with 'hwcap '.

Ok.

r~