On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote:
> On Wed, 15 May 2019 at 16:37, Rich Felker <dal...@libc.org> wrote:
> >
> > On Wed, May 15, 2019 at 01:55:30PM +0000, Szabolcs Nagy wrote:
> > > On 15/05/2019 13:39, Christophe Lyon wrote:
> > > > In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> > > > -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> > > > for executables rather than shared libraries by default.
> > > >
> > > > We also make sure to use the --fdpic assembler option, and select the
> > > > appropriate linker emulation.
> > > >
> > > > At link time, we also default to -pie, unless we are generating a
> > > > shared library or a relocatable file (-r). Note that even for static
> > > > link, we must specify the dynamic linker because the executable still
> > > > has to relocate itself at startup.
> > > >
> > > > We also force 'now' binding since lazy binding is not supported.
> > > >
> > > > We should also apply the same behavior for -Wl,-Ur as for -r, but I
> > > > couldn't find how to describe that in the specs fragment.
> > > ...
> > > > +/* Unless we generate a shared library or a relocatable object, we
> > > > + force -pie. */
> > > > +/* Even with -static, we have to define the dynamic-linker, as we
> > > > + have some relocations to resolve at load time. */
> > > > +#undef SUBTARGET_EXTRA_LINK_SPEC
> > > > +#define SUBTARGET_EXTRA_LINK_SPEC \
> > > > + "%{!mno-fdpic: -m " TARGET_FDPIC_LINKER_EMULATION \
> > > > + "%{!shared:%{!r: -pie}} \
> > > > + %{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
> > > > + "%{mno-fdpic: -m " TARGET_LINKER_EMULATION "}" \
> > > > + "%{!r:%{!mno-fdpic: -z now}}"
> > >
> > > i think -dynamic-linker can be avoided for -static using
> > > -static-pie linking with rcrt0.o
> >
> > Yes, -dynamic-linker should never be used with -static.
>
> So, do you mean dropping completely the line:
> + %{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
> and thus make -static unsupported, forcing users to use -static-pie instead?
Rather I would have -static behave the same as -static-pie. The intent
on musl when we added static pie (before glibc had it) was that
-static plus -pie (including default-pie, if built as default-pie)
would yield static pie output, and our patches still do this. When
static-pie was upstreamed in gcc, it was done differently for
compatibility with legacy versions of glibc. That's not a
consideration for fdpic.
> > > but more importantly: does the abi spec require the sysv dynamic
> > > linker name? that sounds suboptimal (in principle the same os
> >
> > ABI specs typically do this and we just ignore it. BFD contains
> > default dynamic linker strings for all sorts of ABIs, and they're all
> > wrong -- things like /lib/ld64.so.1, etc. I don't think it's worth
> > bothering with fighting the desire of folks writing ABI specs to do
> > this again and again. GCC overrides them all with the actually-correct
> > values when !static.
> >
> > > 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.
> > > > +#undef STARTFILE_SPEC
> > > > +#define STARTFILE_SPEC "%{!mno-fdpic:%{!shared:crtreloc.o%s}} " \
> > > > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC,
> > > > ANDROID_STARTFILE_SPEC)
> > > > diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> > > > index b241ddb..c38b3f4 100644
> > > > --- a/libsanitizer/configure.tgt
> > > > +++ b/libsanitizer/configure.tgt
> > > > @@ -45,6 +45,9 @@ case "${target}" in
> > > > ;;
> > > > sparc*-*-solaris2.11*)
> > > > ;;
> > > > + arm*-*-uclinuxfdpiceabi)
> > > > + UNSUPPORTED=1
> > > > + ;;
> > >
> > > musl libc has fdpic support on sh (e.g. with sh2eb-linux-muslfdpic
> > > target and --enable-fdpic), it can probably support fdpic on arm
> > > too with minimal changes, i assume the target name for that would
> > > be arm-linux-muslfdpiceabi.
> >
> > I plan to add ARM FDPIC support as soon as there is (1) published ABI
> > for relocation types, entry point contract, etc., and (2) there's
>
> The ABI is here:
> https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
>
> > tooling to support it that's either upstream or can be applied as
> > clean patches to recent gcc (as opposed to some fork of gcc4 or
> > whatever it was this got started as). I think those conditions are
> > mostly met now.
> This patch series applies on gcc trunk as of ~2 weeks ago
Excellent news!
> > > so i think it is better to check arm*-*fdpiceabi where the libc
> > > does not matter (so we dont have to patch the same files when
> > > *-muslfdpiceabi support is added).
> >
> Looks sane.
>
> > Yes, that would be appreciated. Maybe we could get musl ldso names
> > added at the same time, too? I think they should just be the same as
> > the existing musl ldso names but with "-fdpic" appended before
> > ".so.1".
> Do you mean updating config/arm/linux-eabi.h and adding -fdpic to the
> 4 musl dynamic linker names?
Yes, conditional on target being fdpic of course.
Rich
