[ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts

[Christophe Lyon]

On Fri, 12 Jul 2019 at 08:49, Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Christophe Lyon <christophe.lyon@st.com> 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  <christophe.lyon@st.com>
> >
> >       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 <features.h>],
>
> 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 <unistd.h>
>
> ...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