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?
> > 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?
> > > +
> > > +#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
> > 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?
> Rich
