Re: RFC: Adding non-PIC executable support to MIPS

[Richard Sandiford <rdsandiford@googlemail.com>]

Daniel Jacobowitz <dan@debian.org> writes:
> - Richard's ld -r support is an addition to the ABI, but does not
> conflict with anything else, so I included it.  I discovered two
> potential problems:
>
>   - If a symbol with STO_MIPS_PIC is localized using objcopy,
>   binutils will ignore the flag.  I don't think this is presently
>   worth implementing but it might be wise to add an error message.
>   I haven't done that yet.
>
>   - Superfluous la25 stubs are suppressed when a PIC2 file uses jal.
>   This is an optimization performed by gcc -mno-shared.  It will not
>   work after ld -r into a non-PIC file; the jump will appear to come
>   from a non-PIC object and be redirected to a new stub.  This is only
>   a minor performance pessimization and I do not plan to fix it.

Yeah, for the record, this second one was actually a deliberate choice.
There's no real object-level information to indicate -mno-sharedness
(unlike "PIC"ness), so any attempt to recognise it would simply be a
heuristic.

The ld -r support was really there for the same reason as the la $25
stubs: to allow "real" PIC and "new" non-PIC to be linked together.
It seems unlikely that you'd have much -mno-shared code to link in if
you're using a "new"-PIC-compatible sysroot.

> - It would be nice to generate, in some cases, both a .MIPS.stubs lazy
> binding stub and a PLT entry.  However, I determined that considerable
> additional work would be required to do this; most likely we'd need
> two entries for the same symbol in the dynamic symbol table so that
> the GOT entry could be associated with the lazy loading stub.  As
> things stand it is possible to link non-PIC and PIC code together, and
> if both call the same function and the non-PIC code takes its address,
> calls to the function from PIC code will be penalized.  I do not
> expect this case to matter.  Most applications will be predominantly
> PIC or non-PIC.

Yeah, FWIW, I think we discussed this in the original three-way thread
last year.  (I think the original proposal was to use PLTs all the time
for "new-PIC" executables.  I remember arguing in favour of keeping
.MIPS.stubs as an option because they're more efficient when handling
the cases they can.  I certainly agree that's it not worth trying to
use both .MIPS.stubs and PLTs for the same function.)

> - I've dropped support for a non-fixed $gp.  This is a handy
> optimization, but it was getting in the way and it was the part of the
> GCC patch Richard had the most comments on.  I can resubmit it after
> everything else is merged.

That's a shame.  It was also the bit I liked best ;)  What went wrong?

(My comments were only minor.)

> - Richard's implementation had __PIC__ mean abicalls.  Our patch
> changed __PIC__ to mean pic2 abicalls only.  I've included that in
> this patch.  My reasoning is that most non-pic non-abicalls code works
> properly even with pic0 abicalls; the only problem is indirect calls
> through a register other than $25.  This lets glibc automatically use
> some more efficient sequences in static applications.

Hmm, OK.  It's the less conservative choice, but I agree it's also
the best performance-wise.

> - I added pointer_equality_needed support to binutils to suppress
> setting st_value to the PLT entry in most cases.
>
> - The GCC new-static-chain.patch causes nested-func-4.exe to fail.
> _mcount is called through a PLT entry, which clobbers $15.  I believe
> we need to add this to MIPS_SAVE_REG_FOR_PROFILING_P.  I didn't fix
> this yet.
>
> - no-fn-name-already-declared.patch removed the call to
> ASM_OUTPUT_TYPE_DIRECTIVE for Linux.  .ent has similar effect, but is
> suppressed by flag_inhibit_size_directive.  This caused glibc's _init
> to be STT_OBJECT, and not get a PIC call stub.  I've changed GCC to
> emit .type for all platforms; Richard, if this should be restricted
> to the status quo (i.e. Linux) let me know.

No, that sounds right to me FWIW.

> Also the STT_FUNC check in the linker was unnecessary now that we only
> use la25 stubs for jump relocations.

Agreed.

Sorry for the bugs, and thanks for fixing them.  I'll try to have
a look at the patches over the weekend.

Richard