Re: Add MIPS -mno-shared support

[Richard Sandiford <richard at codesourcery dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Wed, Mar 22, 2006 at 07:15:53AM +0000, Richard Sandiford wrote:
>> 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.

Wow.  You were thinking of a much more sweeping change than I was then. ;)

The idea of -mno-shared is that it preserves the traditional ABI of
dynamic objects.  I was taking for granted in my reply that we were
talking about ways of doing that while still getting better preformance
where possible.  What you suggest would mean a significant change in the
ABI of the linked objects, but that isn't what -mno-shared is about.

If we're going to reinvent parts of that ABI, we might as well go the
whole hog and design a MIPS ABI that follows more traditional lines.
We might as well add copy relocs at the same time.

I don't know enough details about MIPS' new ABIs to know if that was
one of the ideas they were adopting.

Richard