This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Christophe Lyon <christophe.lyon@linaro.org> writes:
> 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 :-(

Ah, OK.  In that case, it might be worth adding a comment to libtool.m4
that this has been submitted to libtool but not (yet?) accepted, so at
the moment it's a GCC-local change.  That might help the next person
applying libtool patches to understand the history.

>> > 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?

Well, maybe not maintained :-)

But while supporting -shared is AIUI the main goal of FDPIC, I'd be
surprised if it was the right thing to test for all uclinux targets.
Testing *-*-uclinuxfdpic* would be more obvious IMO.  (But there again,
I'm not an expert on this stuff.)

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]