Daniel Jacobowitz <firstname.lastname@example.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
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.
Sorry for the bugs, and thanks for fixing them. I'll try to have
a look at the patches over the weekend.