From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107032 invoked by alias); 12 Jul 2019 13:00:48 -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 107016 invoked by uid 89); 12 Jul 2019 13:00:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=wondered X-HELO: mail-lj1-f194.google.com Received: from mail-lj1-f194.google.com (HELO mail-lj1-f194.google.com) (209.85.208.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Jul 2019 13:00:34 +0000 Received: by mail-lj1-f194.google.com with SMTP id x25so9285254ljh.2 for ; Fri, 12 Jul 2019 06:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gruwLM1A9UI0bnw4nnkULR+sfM6GgRa3X6I0dX0tA1s=; b=QaJUmZaPqx226aRR67nponaDPXdHazZFlNFBj/Ea9ITYvD1vos6KwcAxMKx4QfS3eZ IxBnkFj87H56y1X7YbmFcS6p9ZSglLE7PhEAyVUxg2ax8MLJ3l4uH/CtxB56CSruLl7Q Fi5oX7Q2Si0rwBllD4Swer/8YyvEInXg1gdmFz0Ye16hCtuKTc3uMg5nhlkrombNmMaC Cl3k/0mseELhqOe7uTxmP26m5vduvihEU1o2J7mUyIYVU2lk3N70QrPdoyUYdvzVFnh5 ud4dNUceJu7YblOsZe6esORB5+iA4qUcVPL61apoGtcRj/C4LW+MEWTooevXVsKgyxaL tORA== MIME-Version: 1.0 References: <20190515124006.25840-1-christophe.lyon@st.com> <20190515124006.25840-3-christophe.lyon@st.com> In-Reply-To: From: Christophe Lyon Date: Fri, 12 Jul 2019 13:25:00 -0000 Message-ID: Subject: Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts To: Christophe Lyon , gcc Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00975.txt.bz2 On Fri, 12 Jul 2019 at 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. Yes, this was raised by Joseph when I first posted this patch series last year: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01507.html I sent a patch there: https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg00000.html but didn't get any feedback :-( > > > [...] > > > > 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? So...... Let me bring back a bit of history/context. When we developed FDPIC support in ST several years ago, we used arm-linux-uclibceabi as triplet. But when I posted the binutils patch series, Joseph said it wasn't appropriate and suggested arm-*-uclinuxfdpiceabi instead. https://sourceware.org/ml/binutils/2018-03/msg00324.html This had an impact on the GCC side, because some parts weren't enabled anymore after the triplet change, so I had to introduce this configure* patch to restore the missing features. Then, I wondered about the impact on other uclinux targets, but it was hard to find a supported-supposed-to-work one. I asked for help on the gcc list (https://gcc.gnu.org/ml/gcc/2018-10/msg00154.html), and finally managed to build and test an xtensa toolchain. And this has an impact on the results on xtensa, as I reported in V3 of this patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html But given the little feedback, I'm wondering whether uclinux targets are actually still alive/maintained? > > > 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. As said above, I needed to set ac_has_nanosleep and ac_has_sched_yield so that tests continue to pass after the triplet change. Looks like I got the effect I wanted, but not in the right way indeed. > 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.... Right, I think it could be hardcoded. > > > @@ -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. Indeed. > > > @@ -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, but I'd have to re-run the tests without this hunk to remember which ones fail with enable_clocale_flag=generic. > > > @@ -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 :-) Good catch Thanks a lot for your feedback. Christophe > > Thanks, > Richard