[PATCH] MIPS: microMIPS ASE support

[Joseph S. Myers]

On Tue, 14 Dec 2010, Maciej W. Rozycki wrote:

> > >    /* Calls from 16-bit code to 32-bit code and vice versa require the
> > > -     mode change.  */
> > > -  *cross_mode_jump_p = !info->relocatable
> > > -		       && ((r_type == R_MIPS16_26 && !target_is_16_bit_code_p)
> > > -			   || ((r_type == R_MIPS_26 || r_type == R_MIPS_JALR)
> > > -			       && target_is_16_bit_code_p));
> > > +     mode change.  This is not required for calls to undefined weak
> > > +     symbols, which should never be executed at runtime.  */
> > 
> > But why do we need to go out of our way to check for them?  I'm sure
> > there's a good reason, but the comment doesn't give much clue what it is.
> 
>  Undefined weak symbols are, well, undefined, so they have resolved to nil 
> and are meant never to be jumped to, so we don't want to error out on them 
> just because they do not have the ISA bit set and a JALX therefore 
> required could not be used for some reason, like the invocation being a 
> sibling call or because it would not satisfy the fixed delay slot 
> dependency.
> 
>  So we decide never to make a cross-mode jump in this situation and leave 
> the original jump instruction (i.e. JAL, JALS or JR) in place.  If the 
> instruction is indeed reached, then 1 will be written to the PC rather 
> than 0 that would "canonically" be required here, but the outcome will be 
> the same (assuming the zeroth page is unmapped), i.e. a segfault will 
> happen.
> 
>  Joseph, I reckon you were involved with this piece -- did I get all the 
> context right here?

Yes.  A call to an undefined weak function is equally valid at compile and 
link time and invalid at execution time if executed whether or not the 
code is compiled in such a way as to support cross-mode jumps.  Such a 
call is a call to an undefined function, never a call to an other-mode 
function, and so the linker should never give errors for cases such as 
JALS where it cannot convert to a cross-mode jump.  The original observed 
problem case was statically linking sln with a call to 
__nptl_deallocate_tsd that never gets executed in single-threaded 
programs.

-- 
Joseph S. Myers
joseph@codesourcery.com