Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided

[Christophe Lyon <christophe.lyon@linaro.org>]

On Wed, 15 May 2019 at 18:06, Rich Felker <dalias@libc.org> wrote:
>
> On Wed, May 15, 2019 at 03:59:39PM +0000, Szabolcs Nagy wrote:
> > On 15/05/2019 16:37, Rich Felker wrote:
> > > On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote:
> > >> On Wed, 15 May 2019 at 16:37, Rich Felker <dalias@libc.org> wrote:
> > >>> On Wed, May 15, 2019 at 01:55:30PM +0000, Szabolcs Nagy wrote:
> > >>>> can support both normal elf and fdpic elf so you can test/use
> > >>>> an fdpic toolchain on a system with mmu, but this requires
> > >>>> different dynamic linker name ..otherwise one has to run
> > >>>> executables in a chroot or separate mount namespace to change
> > >>>> the dynamic linker)
> > >>>
> > >>> Indeed, it's a bad idea to make them clash.
> > >>>
> > >>
> > >> Not sure to understand your point: indeed FDPIC binaries work
> > >> on a system with mmu, provided you have the right dynamic
> > >> linker in the right place, as well as the needed runtime libs (libc, etc....)
> > >>
> > >> Do you want me to change anything here?
> > >
> > > I think the concern is that if the PT_INTERP name is the same for
> > > binaries with different ABIs, you wouldn't be able to have both
> > > present in the same root fs, and this would make it more of a pain to
> > > debug fdpic binaries on a full (with-mmu) host.
> > >
> > > musl always uses a different PT_INTERP name for each ABI combination,
> > > so I guess the question is whether uclibc or whatever other libc
> > > you're intending people to use would also want to do this.
> >
> > glibc uses different names now for new abis, so i was expecting
> > some *_DYNAMIC_LINKER update, but it seems uclibc always uses
> > the same fixed name
> >
> > /lib/ld-uClibc.so.0
> >
> > i guess it makes sense for them since iirc uclibc can change
> > its runtime abi based on lot of build time config so having
> > different name for each abi variant may be impractical.
>
> Yes, this "feature" of uclibc was was of the key motivations behind
> the creation of musl... :-)
>

Hi,

I discussed a bit further with Szabolcs on irc, and tried to get some
feedback from uclibc-ng community (none so far)

I propose the following 2 patches on top of this one to address part
of the concerns:
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 67edb42..d7cc923 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -89,7 +89,7 @@
 #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
 #endif
 #define MUSL_DYNAMIC_LINKER \
-  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E "%{mfloat-abi=hard:hf}.so.1"
+  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E
"%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
    use the GNU/Linux version, not the generic BPABI version.  */

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index c38b3f4..92bca69 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -45,7 +45,7 @@ case "${target}" in
        ;;
   sparc*-*-solaris2.11*)
        ;;
-  arm*-*-uclinuxfdpiceabi)
+  arm*-*-fdpiceabi)
        UNSUPPORTED=1
        ;;
   arm*-*-linux*)

However, regarding -staic/-static-pie, it seems I have several options:
(a) add support for static-pie to uclibc-ng. This means creating a new
rcrt1.o or similar, which would embed parts of the dynamic linker into
static-pie executables. This seems to involve quite a bit of work

(b) add support for FDPIC on arm to musl, which I'm not familiar with

(c) declare -static not supported on arm-FDPIC

(d) gather consensus that -static with pt_interp is ok (my preference,
since that's what the current patches do :-)

At this point, I'd prefer to stick with (d), or (c), to avoid further delaying
inclusion of FDPIC support for arm in GCC, and address improvements
later, so that it's not a constantly moving target.

Thanks,

Christophe