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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Thanks to everyone for their kind messages.  I won't drag this out
for non-MIPS folk by replying publicly to each one.

Daniel Jacobowitz <dan@debian.org> writes:
> the GOT cleanups in particular look very useful.

Thanks.  To be clear: the withdrawal was simply for the patches in this
message.  Although the original motivation for the GOT cleanups was to
reduce the amount of wasted space in mostly-non-PIC executables,
they're really a separate change in their own right.  My hope was that,
even without the non-PIC stuff, the new code might be more maintainable
than what we have now.

> We could have done more to keep everyone informed of our progress; I
> could write an essay on why we didn't, but I'd rather not.  We're
> talking internally about how to avoid this unfortunate coincidence in
> the future.  Anyway, there's plenty of blame to go around.

FWIW, I don't blame MTI or CS at all for this.  Duplicated effort is
part of the risk one runs with the model that both you (CS) and I were
following.  (And for the record, I say "I" because the fault was mine
rather than Specifix's.)

When I was doing the work, I was expecting to use the patches as the
basis for a discussion on this list.  And I honestly expected to have to
change some of the details as a result.  E.g. I wasn't sure what the
reaction would be to requiring MIPS II or above.  So it's no surprise
that my version as posted is not going to be used.

And when I learnt about your alternative implementation, I was expecting
some of that implementation to be chosen instead.  The difficulty was
simply that, as you rightly said, MTI are the authority here.  That made
any discussion on this list moot.

That was just an attempt to clarify things rather than force you
into writing an essay ;)

Anyway, enough of that.  Back to technical stuff.  Would it work if we
had stubs like this:

        lui     t7,%hi(.got.plt entry)
        lw      t9,%lo(.got.plt entry)(t7)
        addiu   t8,t7,%lo(.got.plt entry)
        jr      t9
        ...
        lui     t7,%hi(.got.plt entry + 4)  [next entry]
        
and a header like this:

        lui     gp,%hi(.got.plt)
        lw      t9,%lo(.got.plt)(gp)
        addiu   gp,gp,%lo(.got.plt)
        subu    t8,t8,gp
        move    t7,ra
        srl     t8,t8,2
        jalr    t9
        subu    t8,t8,2

(Key for my benefit, 'cos I can only think in terms of numerical
registers:

        t7 = $15
        t8 = $24
        t9 = $25)

The size of the header and first 0x10000 stubs would be the same.
I think it would also preserve the resolver interface while removing
the need for the extra-large .plts.  The only incompatibility I can
see would be that objdump on older executables would not get the
foo@plt symbols right for large indices.

OTOH, perhaps you could argue that the extra complication of the
two PLT entries doesn't count for much given that the code is
already written.  It's just an idea.

Richard