"Maciej W. Rozycki" <ma...@codesourcery.com> writes:
> On Sat, 26 Jan 2013, Richard Sandiford wrote:
>
>> >  How about instead of complicating this we simply add support for 
>> > microMIPS encoding in the PLT?  I think I should be able to squeeze out 
>> > some time next week to dust off and retest the binutils patch I've had 
>> > pending far too long now.  This way we won't have to maintain separate 
>> > cases where tail calls may or may not be made via the PLT.
>> >
>> >  Note that we need that support sooner or later anyway due to the prospect 
>> > of pure-microMIPS processors.
>> 
>> Just so I know: what does the PLT patch do for external functions
>> that are jumped to by both microMIPS and non-microMIPS code?
>
>  Two PLT entries are produced in that case.
>
>  PLT entries are created based on the relocation type referring: R_MIPS_26 
> relocations trigger a standard MIPS PLT entry, R_MICROMIPS_26_S1 
> relocations trigger a microMIPS PLT entry.  Other relocations reuse a PLT 
> entry already produced for one of the jump relocations, or if none 
> present, then they make an own PLT entry according to ELF file header 
> flags: if EF_MIPS_ARCH_ASE_MICROMIPS is set, then a microMIPS entry is 
> produced, otherwise a standard MIPS one.  Therefore depending on 
> relocations seen up to two entries can be produced, encoded differently so 
> that there is no need to switch modes with direct jumps.
>
>  If all the individual PLT entries ultimately produced are microMIPS code, 
> then the PLT header is built as microMIPS code as well, otherwise it's 
> standard MIPS code.  This guarantees no standard MIPS code is produced in 
> the PLT if there's none already in the executable (and vice versa).

Thanks, sounds good!  In that case, yeah, let's leave the TARGET_ABICALLS_PIC0
part out (but keep the rest of mips_call_may_need_jalx_p).

For avoidance of doubt: I don't think there's any need to wait for the
linker patches before sending the updated GCC patch.  The GCC patch can
only go in 4.9 anyway, and the new PLT code won't be avaiable until 2.24,
so there's plenty of time on both sides.  Testing the GCC patch against
Mentor's linker is fine with me.

Richard

Reply via email to