From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77335 invoked by alias); 30 Aug 2019 14:31:07 -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 77320 invoked by uid 89); 30 Aug 2019 14:31:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Aug 2019 14:31:06 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CED603086202; Fri, 30 Aug 2019 14:31:04 +0000 (UTC) Received: from localhost (unknown [10.33.36.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7ACEA19C69; Fri, 30 Aug 2019 14:31:04 +0000 (UTC) Date: Fri, 30 Aug 2019 14:40:00 -0000 From: Jonathan Wakely To: Christophe Lyon Cc: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com, libstdc++@gcc.gnu.org Subject: Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts Message-ID: <20190830143103.GM9487@redhat.com> References: <20190515124006.25840-1-christophe.lyon@st.com> <20190515124006.25840-3-christophe.lyon@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.12.0 (2019-05-25) X-SW-Source: 2019-08/txt/msg02083.txt.bz2 On 29/08/19 16:54 +0200, Christophe Lyon wrote: >On 12/07/2019 08:49, Richard Sandiford wrote: >>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. >> >I added a comment to libtool.m4 about this. > >>>[...] >>> >>>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? >I don't think so, now restricted to -*-uclinuxfdpic* > >> >>>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... > >I've now split the patch into two parts (both attached here) >> >>>@@ -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. >> >Right, now fixed. > >>>@@ -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. >Indeed. > >> >>>@@ -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 :-) > >Right :-) > >Thanks, > >Christophe > >> >>Thanks, >>Richard >>. >> > >From 81c84839b8f004b7b52317850f27f58e05bec6ad Mon Sep 17 00:00:00 2001 >From: Christophe Lyon >Date: Fri, 4 May 2018 15:11:35 +0000 >Subject: [ARM/FDPIC v6 02/24] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in > configure scripts > >The new arm-uclinuxfdpiceabi target behaves pretty much like >arm-linux-gnueabi. In order the enable the same set of features, we s/In order the enable/In order to enable/ The libstdc++ part is OK for trunk.