From: Richard Sandiford <rdsandiford@googlemail.com>
To: binutils@sourceware.org
Cc: gcc@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: RFC: Adding non-PIC executable support to MIPS
Date: Wed, 02 Jul 2008 20:55:54 +0100 [thread overview]
Message-ID: <87abh0m56d.fsf@firetop.home> (raw)
In-Reply-To: <20080702120829.GA12595@caradoc.them.org> (Daniel Jacobowitz's message of "Wed\, 2 Jul 2008 08\:08\:29 -0400")
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
next prev parent reply other threads:[~2008-07-02 19:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-28 17:58 RFC: Adding non-PIC executable support to MIPS Richard Sandiford
2008-06-30 20:59 ` David VomLehn
2008-06-30 21:19 ` Daniel Jacobowitz
2008-06-30 21:28 ` David VomLehn
2008-07-01 20:22 ` Daniel Jacobowitz
2008-07-01 20:43 ` Richard Sandiford
2008-07-01 22:02 ` Richard Sandiford
2008-07-02 7:00 ` Adam Nemet
2008-07-02 10:13 ` Thiemo Seufer
2008-07-02 12:08 ` Daniel Jacobowitz
2008-07-02 19:55 ` Richard Sandiford [this message]
2008-07-02 20:29 ` Daniel Jacobowitz
2008-07-24 16:16 ` Daniel Jacobowitz
2008-07-24 20:17 ` Daniel Jacobowitz
2008-07-24 20:24 ` Richard Sandiford
2008-07-24 20:56 ` Daniel Jacobowitz
2008-07-27 9:10 ` Richard Sandiford
2008-07-27 21:36 ` Mark Mitchell
2008-07-28 19:43 ` Richard Sandiford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87abh0m56d.fsf@firetop.home \
--to=rdsandiford@googlemail.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox