This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] MIPS: Use R_MICROMIPS_JALR rather than R_MIPS_JALR in microMIPS code
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 23 Nov 2016 17:49:35 +0000
- Subject: Re: [PATCH] MIPS: Use R_MICROMIPS_JALR rather than R_MIPS_JALR in microMIPS code
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.17.1611231217350.10580@tp.orcam.me.uk>
On Wed, 23 Nov 2016, Maciej W. Rozycki wrote:
> In a microMIPS compilation of `.init' code use the R_MICROMIPS_JALR
> relocation intended for PIC call relaxation in microMIPS code rather
> than the corresponding R_MIPS_JALR relocation meant for regular MIPS
> code only.
>
> * sysdeps/mips/mips32/crti.S (JALR_RELOC): New macro.
> (_init): Use it in place of hardcoded R_MIPS_JALR.
> * sysdeps/mips/mips64/n32/crti.S (JALR_RELOC): New macro.
> (_init): Use it in place of hardcoded R_MIPS_JALR.
> * sysdeps/mips/mips64/n64/crti.S (JALR_RELOC): New macro.
> (_init): Use it in place of hardcoded R_MIPS_JALR.
> ---
> No regressions with the `mips-mti-linux-gnu' target in o32 regular MIPS
> and microMIPS multilib testing and neither in n32 and n64 regular MIPS
> multilib testing.
>
> OK to apply?
OK.
It would probably make sense to add at least one mips16 and one microMIPS
configuration to build-many-glibcs.py so build failures for such
configurations are more readily detected (though I suppose a wrong
relocation like this might not result in a build failure?).
--
Joseph S. Myers
joseph@codesourcery.com