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). Maciej
