This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Daniel Jacobowitz <dan@codesourcery.com> writes:
> 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?

No, you're probably right.  Sorry for missing this.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]