Re: RFC: Adding non-PIC executable support to MIPS

[Daniel Jacobowitz <dan at codesourcery dot com>]

Hi Richard,

I've been working on the merge of the two non-PIC implementations, as
I said I would.  It's going slowly but well.  When I examined the
differences between a couple of test programs, I saw one thing I had a
question about...

On Sat, Jun 28, 2008 at 06:58:58PM +0100, Richard Sandiford wrote:
> We can handle this situation in two ways.  If the target function
> "foo" starts a section, and the section is not too heavily-aligned,
> we can insert:
> 
>         lui     $25,%hi(1f)
>         addiu   $25,$25,%lo(1f)
> 1:
> 
> immediately before it.  This code goes in a new section and is padded
> with leading nops if necessary.  "foo" then resolves to the "lui"
> instruction, so that all references to "foo" have the same address.
> 
> I think this is an important optimisation.  In practice, most uses
> of PIC in executables will come from static libraries, which usually
> have one function per section.
> 
> However, if "foo" doesn't start a section, the linker must create
> a separate trampoline of the form:
> 
> foo:
>         lui     $25,%hi(.pic.foo)
>         j       .pic.foo
>         addiu   $25,$25,%lo(.pic.foo)
> 
> where .pic.foo is the original PIC form of "foo".  Again, "foo"
> resolves to this trampoline, so that all references to "foo" have the
> same address.

There are only three types of calls:

  - Direct calls, using j / jal, within one linked object.

  - Direct-seeming calls which are redirected through the PLT.

  - Indirect calls through a register.

In the first kind of call, we need to set up $25.  But both the PLT
call and the ABI-conformant indirect call set up $25 already, since
they don't know whether the target function will be in a shared
library.  So I think it's safe to leave the address of the function
unchanged, pointing at the PIC version which expects $25 to be already
prepared.

This matches what our implementation did for stubs, and I haven't seen
any problems with it yet.  I'm concerned that moving the symbol
definition might upset GDB, plus I'd like to avoid the stub
instructions for indirect calls if they're not necessary.

Do you see anything I've missed here?

-- 
Daniel Jacobowitz
CodeSourcery