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.
> 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.
> > +
> > +#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
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.
> 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).
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".
Rich
