RE: [PATCH] MIPS/binutils: microMIPS linker relaxation fixes

["Fu, Chao-Ying" <fu at mips dot com>]

Maciej W. Rozycki wrote:

>  I have now cc-ed the original authors of this code in case they have 
> anything to add.
> 
> On Tue, 15 Nov 2011, Richard Sandiford wrote:
> 
> > >  So I have actually given it some more thought and my 
> understanding of the 
> > > ABI remains that while orphaned R_MIPS_LO16 relocations 
> are indeed 
> > > permitted, they still must be preceded by a corresponding 
> R_MIPS_HI16, 
> > > although that is not required to be adjacent.  I believe 
> this is only 
> > > permitted to allow cases like you quoted to avoid 
> unnecessary extra code 
> > > to add missing R_MIPS_HI16 relocations.
> > 
> > There are still potential problems though.  We deliberately 
> allow things like:
> > 
> >         lui     $4,%hi(foo)
> >         lw      $6,%lo(foo)($4)
> >         lw      $7,%lo(foo+4)($4)
> >         ...
> >         .align  8
> > foo:
> >         .word   X, Y
> > 
> > and foo is allowed to be in a text section.  Does your 
> patch ensure that
> > foo remains 8-byte aligned, even if we relax code earlier 
> in the section?
> 
>  Sigh, you're right -- I wish we realised this earlier on.  No, the 
> alignment of foo will get broken of course just as alignment 
> of standard 
> MIPS code would, as noted with the original submission of 
> this update.  
> Of course if you run this under Linux, the you won't notice 
> unless you 
> observe the performance drop badly.

  I don't think GCC puts data inside .text section under MIPS/microMIPS mode.
(However, MIPS16 does have similar code, and users can disable this
behavior with -mcode-readable=no.)
For hand-written assembly code, linker relaxation may not be performed to avoid breakage.
We need to think more carefully about the usage of linker relaxation, as there are many traps.
Maybe at the end it is not feasible to have linker relaxation.  Thanks!

Regards,
Chao-ying