From: Christophe Lyon <christophe.lyon@linaro.org>
To: Christophe Lyon <christophe.lyon@st.com>,
gcc Patches <gcc-patches@gcc.gnu.org>,
Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
Date: Fri, 12 Jul 2019 13:25:00 -0000 [thread overview]
Message-ID: <CAKdteOZCnWZy8N-+tcvZfac13M+aJFTZW3PwJtS0u5Jf1fyO9A@mail.gmail.com> (raw)
In-Reply-To: <mptims7iw7t.fsf@arm.com>
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
next prev parent reply other threads:[~2019-07-12 13:00 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 12:40 [ARM/FDPIC v5 00/21] FDPIC ABI for ARM Christophe Lyon
2019-05-15 12:40 ` [ARM/FDPIC v5 01/21] [ARM] FDPIC: Add -mfdpic option support Christophe Lyon
2019-07-16 10:18 ` Richard Sandiford
2019-08-29 15:08 ` Christophe Lyon
2019-08-30 10:06 ` Richard Sandiford
2019-05-15 12:41 ` [ARM/FDPIC v5 05/21] [ARM] FDPIC: Fix __do_global_dtors_aux and frame_dummy generation Christophe Lyon
2019-07-12 6:49 ` Richard Sandiford
2019-07-12 14:25 ` Christophe Lyon
2019-08-29 15:39 ` Christophe Lyon
2019-08-30 8:41 ` Richard Sandiford
2019-05-15 12:41 ` [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts Christophe Lyon
2019-07-12 7:44 ` Richard Sandiford
2019-07-12 13:25 ` Christophe Lyon [this message]
2019-07-12 13:28 ` Richard Sandiford
2019-08-29 15:14 ` Christophe Lyon
2019-08-30 9:30 ` Richard Sandiford
2019-08-30 14:48 ` Christophe Lyon
2019-08-30 15:15 ` Richard Sandiford
2019-09-02 7:51 ` Christophe Lyon
2019-09-02 8:31 ` Richard Sandiford
2019-08-30 14:40 ` Jonathan Wakely
2019-05-15 12:41 ` [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided Christophe Lyon
2019-05-15 13:55 ` Szabolcs Nagy
2019-05-15 14:37 ` Rich Felker
2019-05-15 15:12 ` Christophe Lyon
2019-05-15 15:37 ` Rich Felker
2019-05-15 15:59 ` Szabolcs Nagy
2019-05-15 16:07 ` Rich Felker
2019-05-21 15:29 ` Christophe Lyon
2019-05-21 15:48 ` Rich Felker
2019-05-22 8:39 ` Szabolcs Nagy
2019-05-22 8:45 ` Christophe Lyon
2019-05-23 12:45 ` Christophe Lyon
2019-07-16 10:38 ` Richard Sandiford
2019-07-16 20:00 ` Rich Felker
2019-08-01 10:13 ` Christophe Lyon
2019-08-06 14:28 ` Richard Sandiford
2019-08-29 15:14 ` Christophe Lyon
2019-08-30 9:40 ` Richard Sandiford
2019-05-15 12:41 ` [ARM/FDPIC v5 04/21] [ARM] FDPIC: Add support for FDPIC for arm architecture Christophe Lyon
2019-07-16 12:33 ` Richard Sandiford
2019-08-20 17:13 ` Christophe Lyon
2019-08-29 15:39 ` Christophe Lyon
2019-09-02 16:12 ` Richard Sandiford
2019-09-02 20:04 ` Christophe Lyon
2019-09-03 8:40 ` Richard Sandiford
2019-09-04 19:59 ` Christophe Lyon
2019-09-05 8:03 ` Richard Sandiford
2019-05-15 12:42 ` [ARM/FDPIC v5 06/21] [ARM] FDPIC: Add support for c++ exceptions Christophe Lyon
2019-08-30 9:31 ` Kyrill Tkachov
2019-08-30 14:44 ` Jonathan Wakely
2019-05-15 12:42 ` [ARM/FDPIC v5 07/21] [ARM] FDPIC: Avoid saving/restoring r9 on stack since it is read-only Christophe Lyon
2019-07-16 10:42 ` Kyrill Tkachov
2019-05-15 12:43 ` [ARM/FDPIC v5 09/21] [ARM] FDPIC: Add support for taking address of nested function Christophe Lyon
2019-07-16 11:53 ` Kyrill Tkachov
2019-07-16 13:31 ` Kyrill Tkachov
2019-07-31 14:48 ` Christophe Lyon
2019-08-29 15:40 ` Christophe Lyon
2019-08-30 8:54 ` Kyrill Tkachov
2019-05-15 12:43 ` [ARM/FDPIC v5 10/21] [ARM] FDPIC: Implement TLS support Christophe Lyon
2019-09-04 14:16 ` Kyrill Tkachov
2019-09-04 20:03 ` Christophe Lyon
2019-09-09 8:54 ` Christophe Lyon
2019-05-15 12:43 ` [ARM/FDPIC v5 08/21] [ARM] FDPIC: Enforce local/global binding for function descriptors Christophe Lyon
2019-07-16 10:51 ` Kyrill Tkachov
2019-05-15 12:44 ` [ARM/FDPIC v5 13/21] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture Christophe Lyon
2019-08-29 15:37 ` Kyrill Tkachov
2019-09-05 8:30 ` Christophe Lyon
2019-09-05 8:32 ` Christophe Lyon
2019-09-05 20:56 ` Ian Lance Taylor
2019-09-05 9:03 ` Kyrill Tkachov
2019-09-09 8:58 ` Christophe Lyon
2019-05-15 12:44 ` [ARM/FDPIC v5 12/21] [ARM] FDPIC: Restore r9 after we call __aeabi_read_tp Christophe Lyon
2019-08-29 15:40 ` Christophe Lyon
2019-08-29 15:44 ` Kyrill Tkachov
2019-05-15 12:44 ` [ARM/FDPIC v5 11/21] [ARM] FDPIC: Add support to unwind FDPIC signal frame Christophe Lyon
2019-09-04 14:19 ` Kyrill Tkachov
2019-05-15 12:45 ` [ARM/FDPIC v5 15/21] [ARM][testsuite] FDPIC: Adjust scan-assembler patterns Christophe Lyon
2019-07-19 8:54 ` Kyrill Tkachov
2019-05-15 12:45 ` [ARM/FDPIC v5 14/21] [ARM][testsuite] FDPIC: Skip unsupported tests Christophe Lyon
2019-07-19 8:52 ` Kyrill Tkachov
2019-05-15 12:45 ` [ARM/FDPIC v5 16/21] [ARM][testsuite] FDPIC: Skip tests that don't work in PIC mode Christophe Lyon
2019-07-19 8:56 ` Kyrill Tkachov
2019-05-15 12:46 ` [ARM/FDPIC v5 19/21] [ARM][testsuite] FDPIC: Adjust pr43698.c to avoid clash with uclibc Christophe Lyon
2019-07-19 9:00 ` Kyrill Tkachov
2019-05-15 12:46 ` [ARM/FDPIC v5 18/21] [ARM][testsuite] FDPIC: Enable tests on pie_enabled targets Christophe Lyon
2019-07-19 8:59 ` Kyrill Tkachov
2019-07-22 19:50 ` Mike Stump
2019-05-15 12:46 ` [ARM/FDPIC v5 17/21] [ARM][testsuite] FDPIC: Handle *-*-uclinux* Christophe Lyon
2019-07-19 8:57 ` Kyrill Tkachov
2019-07-22 19:37 ` Mike Stump
2019-05-15 12:47 ` [ARM/FDPIC v5 21/21] [ARM] FDPIC: Handle stack-protector combined patterns Christophe Lyon
2019-07-19 9:40 ` Kyrill Tkachov
2019-05-15 12:47 ` [ARM/FDPIC v5 20/21] [ARM][testsuite] FDPIC: Skip tests using architectures unsupported by FDPIC Christophe Lyon
2019-07-19 9:03 ` Kyrill Tkachov
2019-09-06 8:01 ` Christophe Lyon
2019-09-06 8:28 ` Kyrill Tkachov
2019-09-06 9:10 ` Christophe Lyon
2019-09-06 17:44 ` Christophe Lyon
2019-09-09 8:38 ` Christophe Lyon
2019-05-23 12:46 ` [ARM/FDPIC v5 00/21] FDPIC ABI for ARM Christophe Lyon
2019-06-04 12:57 ` Christophe Lyon
2019-06-06 12:36 ` Christophe Lyon
2019-06-17 11:42 ` Christophe Lyon
2019-07-01 12:16 ` Christophe Lyon
2019-07-08 14:28 ` Christophe Lyon
2019-07-16 9:13 ` Christophe Lyon
2019-08-29 14:54 ` Christophe Lyon
2019-08-29 16:29 ` Christophe Lyon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKdteOZCnWZy8N-+tcvZfac13M+aJFTZW3PwJtS0u5Jf1fyO9A@mail.gmail.com \
--to=christophe.lyon@linaro.org \
--cc=christophe.lyon@st.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.sandiford@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).