Re: [RFC][PATCH] MIPS ifunc for binutils

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <jack.carter@imgtec.com> writes:
> So I don't mess up the conversation, I'll make the easy changes so far 
> suggested, play with preemption and resubmit the patch for review. It 
> will allow me to focus on the ABI issues going forward. I also have a 
> request to produce a formal ABI doc for the MIPS ifunc implementation. I 
> will add that as well so that when we come to agreement, we will have 
> agreed to the same thing.
>
> When resubmitting, do I change the subject of the email. Otherwise I 
> will keep it as "Re: [RFC][PATCH] MIPS ifunc for binutils".

Not sure there's a convention either way on that.  Keeping the same
thread is certainly fine by me FWIW.

> I worked for MIPS and then SGI for a long time so my nomenclature needs 
> to be updated to fit binutils. For me there were 3 flavors of what we 
> called executables:
>      non-shared,
>      call-shared (CPIC - not exactly what it is in gnu land)
>      shared (PIC).
>
> I think from what you have stated that these translate to:
>      normal executable (ET_EXEC)
>      PIE (ET_DYN)
>      DSO (ET_DYN)

Well, at the compiler level, I think they line up like this:

  non-shared      => -mno-abicalls  (default on mips*-elf*)
  call-shared     => -mabicalls -mno-shared  (default on mips*-linux-gnu)
  shared          => -mabicalls -fPIC

although I've never been too sure what was and wasn't allowed for
traditional call-shared.  (It's over 8 years since I last had access
to MIPSpro.)  -mno-shared is pretty aggressive in trying to use %hi/%lo
and direct JALs for anything it knows binds locally.  It also avoids
using the incoming value of $25, since LUI/ADDIU of _gp (or equivalent)
is faster.  So this mode is deliberately not position-independent but
still uses the ABI-defined methods for handling external symbols and calls.

There's also:

  -mabicalls -mshared

which was the traditional default behaviour for mips*-linux-gnu.
It uses PIC-style accesses for everything, but assumes that
locally-defined symbols also _bind_ locally.  That means for example
that calls to a global function f in the same translation unit can be
inlined, which isn't possible for DSOs because a later DSO or executable
could override f with a different definition.  This mode is suitable for
PIEs and is what you get for "gcc -fpie" and "gcc -fPIE".

Then of course there's the newer PLT and copy-reloc scheme, which is
still opt-in.

So the -mabicalls modes can be ranked in increasing order of generality by:

  (1) -mabicalls -mplt
  (2) -mabicalls -mno-shared
  (3) -mabicalls -mshared/-fpie/-fPIE
  (4) -mabicalls -fpic/-fPIC

where the difference between (3) and (4) is purely binding assumptions.
All four are link-compatible and the result of "ld -r"-ing a mixture of
them has the same generality as the least-general input.

As far as the linker output goes:

Normal executables (ET_EXECs) can be made from any of the above, with
the proviso that -mabicalls and -mno-abicalls are not link-compatible.
E.g. an ET_EXEC could contain a mixture of (1), (2), (3) and (4)
in extreme cases.  On the other hand it could just contain (1) or
just contain (4).

I don't think the traditional tools supported true PIEs, which are
executables that are linked as ET_DYNs and which can be loaded at any
address.  They need (3) or (4) above.

DSOs can be successfully linked with (3) or (4) above, but only (4)
should be used in practice, since (3) may prevent symbol preemption
and so (for example) could break the C++ one-definition rule.

> I will change to use the gnu version. I still struggle with not calling 
> the dynamic linker "rld". Old dog, new tricks.

Heh, I can definitely sympathise :-)

Thanks,
Richard