Daniel Jacobowitz <dan@xxxxxxxxxx> 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
