[Top] [All Lists]

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

Subject: Re: RFC: Adding non-PIC executable support to MIPS
From: Daniel Jacobowitz <>
Date: Thu, 24 Jul 2008 12:16:20 -0400
In-reply-to: <87y74pxwyl.fsf@firetop.home>
Original-recipient: rfc822;
References: <87y74pxwyl.fsf@firetop.home>
User-agent: Mutt/1.5.17 (2008-05-11)
On Sat, Jun 28, 2008 at 06:58:58PM +0100, Richard Sandiford wrote:
> I suppose the good news is that we can pick the best bits of each
> implementation as the official one.

And that's what I've been working on.  We had to pick some bits from
the CodeSourcery implementation that I wouldn't describe as "best" -
arbitrarily different or a bit less efficient - due to ABI constraints
we've already discussed.  But I was able to pick up clever bits from
both sets as I combined them.

I have attached patch for gdb and glibc.  These are only slightly
changed from my last posting.  I've also attached quilt series for
binutils and gcc; these are based on Richard's.  I disabled a couple
of patches that had already been applied to binutils HEAD, but
otherwise did not change any of Richard's patches.  I added a
cs-plts.patch to the end of both series.  This form is probably better
for review and discussion than it would be for committing; the bits
from cs-plts.patch belong in several earlier patches in each series,
but I decided this would be an unworkable way to compare patches.

I have tested this thoroughly on mips-linux and somewhat on N32 / N64
(binutils testsuites and GCC's builtins.exp).  The testing was before
some last minute fixes, though, and I've only retested individual
tests since.  I'll be rerunning a complete test cycle, but I wanted to
get this posted and I'm 99% sure I didn't break anything (this time).

All comments welcome - Richard, especially from you.  How would you
like to proceed?  I think the first step should be to get your other
binutils/gcc patches merged, including MIPS16 PIC; I used those as a
base.  But see a few of the notes for potential problems with those

My notes about the merge:

- Richard's ld -r support is an addition to the ABI, but does not
conflict with anything else, so I included it.  I discovered two
potential problems:

  - If a symbol with STO_MIPS_PIC is localized using objcopy,
  binutils will ignore the flag.  I don't think this is presently
  worth implementing but it might be wise to add an error message.
  I haven't done that yet.

  - Superfluous la25 stubs are suppressed when a PIC2 file uses jal.
  This is an optimization performed by gcc -mno-shared.  It will not
  work after ld -r into a non-PIC file; the jump will appear to come
  from a non-PIC object and be redirected to a new stub.  This is only
  a minor performance pessimization and I do not plan to fix it.

- Some mips16 call stubs called through $1 instead of $25.  I believe
I've fixed them all, though I am not set up to test mips16.  I don't
think this would have caused a problem, since as far as I can tell
the indirect jumps are only used when the target is mips16; but better
safe than sorry so we now follow the ABI.

- It would be nice to generate, in some cases, both a .MIPS.stubs lazy
binding stub and a PLT entry.  However, I determined that considerable
additional work would be required to do this; most likely we'd need
two entries for the same symbol in the dynamic symbol table so that
the GOT entry could be associated with the lazy loading stub.  As
things stand it is possible to link non-PIC and PIC code together, and
if both call the same function and the non-PIC code takes its address,
calls to the function from PIC code will be penalized.  I do not
expect this case to matter.  Most applications will be predominantly
PIC or non-PIC.

- I've dropped support for a non-fixed $gp.  This is a handy
optimization, but it was getting in the way and it was the part of the
GCC patch Richard had the most comments on.  I can resubmit it after
everything else is merged.

- Richard's implementation had __PIC__ mean abicalls.  Our patch
changed __PIC__ to mean pic2 abicalls only.  I've included that in
this patch.  My reasoning is that most non-pic non-abicalls code works
properly even with pic0 abicalls; the only problem is indirect calls
through a register other than $25.  This lets glibc automatically use
some more efficient sequences in static applications.

- With Richard's patches I saw a crash building libstdc++ with symbol
versioning.  This was caused by not following indirect symbols in all
cases during check_relocs; we would assign a GGA_NORMAL GOT slot to
an indirect symbol, and trigger an assertion failure while removing
it.  This is sensitive to link order.

- A small change in glibc fixes the canonical address of functions
with PLT entries, when referenced from PIC code.

- I added pointer_equality_needed support to binutils to suppress
setting st_value to the PLT entry in most cases.

- The GCC new-static-chain.patch causes nested-func-4.exe to fail.
_mcount is called through a PLT entry, which clobbers $15.  I believe
we need to add this to MIPS_SAVE_REG_FOR_PROFILING_P.  I didn't fix
this yet.

- no-fn-name-already-declared.patch removed the call to
ASM_OUTPUT_TYPE_DIRECTIVE for Linux.  .ent has similar effect, but is
suppressed by flag_inhibit_size_directive.  This caused glibc's _init
to be STT_OBJECT, and not get a PIC call stub.  I've changed GCC to
emit .type for all platforms; Richard, if this should be restricted
to the status quo (i.e. Linux) let me know.  Also the STT_FUNC check
in the linker was unnecessary now that we only use la25 stubs for
jump relocations.

Daniel Jacobowitz

Attachment: gcc-quilt.tar.gz
Description: Binary data

Attachment: binutils-quilt.tar.gz
Description: Binary data

Attachment: gdb-nonpic.patch
Description: Text Data

Attachment: glibc-ports-nonpic.patch
Description: Text Data

Attachment: glibc-relocs.patch
Description: Text Data

Attachment: glibc-longlong.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>