Re: Add MIPS -mno-shared support

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Mar 22, 2006 at 07:15:53AM +0000, Richard Sandiford wrote:
> Yeah, I wondered about that too, but I think we should only do it if we
> add an ELF flag.  I don't like the sound of things like...
> 
> > The linker should be able to warn about a mismatch - it will see the
> > direct j/jal relocation, and the old GOT load sequence.
> 
> ...all that much.  And I agree we'd need the linker to detect mismatches
> _somehow_.  It would be far too easy to make mistakes otherwise.

Oh, I don't know - if we add an ELF flag, we become incompatible with
other toolchains.  I think having the linker detect the actual problem
would be more elegant.  The only case I can think of where it wouldn't
work would be MIPS code which did PIC accesses relative to the incoming
$25 rather than loading the GOT value.

> Also, even if -mno-shared usage does become more common in future,
> the change we're talking about would only make a difference if the user
> carefully marks every locally-binding but not locally-defined function
> with some visibility attribute, so that we know at compile time that
> we can call it directly.  I wonder if that practice will become common
> enough for the extra complication to pay off?  I wasn't really convinced.

Ah, but this isn't completely true.  The benefit of loading from the
GOT is to allow symbol preemption.  If we have traditional-looking PLT
stubs within the executable, then the executable can call externally
defined functions as if they were local to the executable, and the stub
can load the GOT pointer using the new, compact sequence.  So there's
no need to mark functions: -mno-shared can call all functions this way.

I'd want to see some performance numbers on doing that, though.  On
the one hand, it eliminates the bulk of GOT loads in the main
executable; on the other, it adds GOT loads to calls in shared
libraries.  It might depend on frequency.

-- 
Daniel Jacobowitz
CodeSourcery