From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83097 invoked by alias); 12 Jul 2019 06:49:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 83089 invoked by uid 89); 12 Jul 2019 06:49:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SEM_URI,SEM_URIRED,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Jul 2019 06:49:13 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 35286337; Thu, 11 Jul 2019 23:49:12 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.39]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3D3EA3F59C; Thu, 11 Jul 2019 23:51:09 -0700 (PDT) From: Richard Sandiford To: Christophe Lyon Mail-Followup-To: Christophe Lyon ,, richard.sandiford@arm.com Cc: Subject: Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts References: <20190515124006.25840-1-christophe.lyon@st.com> <20190515124006.25840-3-christophe.lyon@st.com> Date: Fri, 12 Jul 2019 07:44:00 -0000 In-Reply-To: <20190515124006.25840-3-christophe.lyon@st.com> (Christophe Lyon's message of "Wed, 15 May 2019 14:39:27 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-07/txt/msg00928.txt.bz2 Christophe Lyon writes: > The new arm-uclinuxfdpiceabi target behaves pretty much like > arm-linux-gnueabi. In order the enable the same set of features, we > have to update several configure scripts that generally match targets > like *-*-linux*: in most places, we add *-uclinux* where there is > already *-linux*, or uclinux* when there is already linux*. > > In gcc/config.gcc and libgcc/config.host we use *-*-uclinuxfdpiceabi > because there is already a different behaviour for *-*uclinux* target. > > In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared > libraries support is required, as uclinux does not guarantee that. > > 2019-XX-XX Christophe Lyon > > config/ > * futex.m4: Handle *-uclinux*. > * tls.m4 (GCC_CHECK_TLS): Likewise. > > gcc/ > * config.gcc: Handle *-*-uclinuxfdpiceabi. > > libatomic/ > * configure.tgt: Handle arm*-*-uclinux*. > * configure: Regenerate. > > libgcc/ > * config.host: Handle *-*-uclinuxfdpiceabi. > > libitm/ > * configure.tgt: Handle *-*-uclinux*. > * configure: Regenerate. > > libstdc++-v3/ > * acinclude.m4: Handle uclinux*. > * configure: Regenerate. > * configure.host: Handle uclinux* > > * libtool.m4: Handle uclinux*. Has the libtool.m4 patch been submitted to upstream libtool? I think this is supposed to be handled by submitting there first and then cherry-picking into gcc, so that the change isn't lost by a future import. > [...] > > diff --git a/config/tls.m4 b/config/tls.m4 > index 1a5fc59..a487aa4 100644 > --- a/config/tls.m4 > +++ b/config/tls.m4 > @@ -76,7 +76,7 @@ AC_DEFUN([GCC_CHECK_TLS], [ > dnl Shared library options may depend on the host; this check > dnl is only known to be needed for GNU/Linux. > case $host in > - *-*-linux*) > + *-*-linux* | -*-uclinux*) > LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS" > ;; > esac Is this right for all uclinux targets? > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > index 84258d8..cb0fdc5 100644 > --- a/libstdc++-v3/acinclude.m4 > +++ b/libstdc++-v3/acinclude.m4 It'd probably be worth splitting out the libstdc++-v3 bits and submitting them separately, cc:ing libstdc++@gcc.gnu.org. But... > @@ -1404,7 +1404,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [ > ac_has_nanosleep=yes > ac_has_sched_yield=yes > ;; > - gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu) > + gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu | uclinux*) > AC_MSG_CHECKING([for at least GNU libc 2.17]) > AC_TRY_COMPILE( > [#include ], is this the right thing to do? It seems odd to be testing the glibc version for uclibc. Do you want to support multiple possible settings of ac_has_clock_monotonic and ac_has_clock_realtime? Or could you just hard-code the values, given particular baseline assumptions about the version of uclibc etc.? Hard-coding would then make.... > @@ -1526,7 +1526,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [ > > if test x"$ac_has_clock_monotonic" != x"yes"; then > case ${target_os} in > - linux*) > + linux* | uclinux*) > AC_MSG_CHECKING([for clock_gettime syscall]) > AC_TRY_COMPILE( > [#include ...this redundant. > @@ -2415,7 +2415,7 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [ > # Default to "generic". > if test $enable_clocale_flag = auto; then > case ${target_os} in > - linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu) > + linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu | uclinux*) > enable_clocale_flag=gnu > ;; > darwin*) This too seems to be choosing a glibc setting for a uclibc target. > @@ -2661,7 +2661,7 @@ AC_DEFUN([GLIBCXX_ENABLE_ALLOCATOR], [ > # Default to "new". > if test $enable_libstdcxx_allocator_flag = auto; then > case ${target_os} in > - linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu) > + linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu | uclinux*) > enable_libstdcxx_allocator_flag=new > ;; > *) The full case is: # Probe for host-specific support if no specific model is specified. # Default to "new". if test $enable_libstdcxx_allocator_flag = auto; then case ${target_os} in linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu) enable_libstdcxx_allocator_flag=new ;; *) enable_libstdcxx_allocator_flag=new ;; esac fi which looks a bit redundant :-) Thanks, Richard