public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@wasabisystems.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: paul@codesourcery.com, binutils@sources.redhat.com, rearnsha@arm.com
Subject: Re: [arm] EABI annotation of thumb symbols.
Date: Thu, 04 Nov 2004 15:42:00 -0000	[thread overview]
Message-ID: <m33bzplixk.fsf@gossamer.airs.com> (raw)
In-Reply-To: <20041104150856.GA23650@nevyn.them.org>

Daniel Jacobowitz <drow@false.org> writes:

> > That said, I'm building Thumb shared libraries in which the PLT takes
> > up 120K, or some 4.5% of the text section size.  It's probably
> > possible to use version scripts to force some of the symbols to be
> > local, but this source code is neither from us nor from our customer,
> > so that is not a simple task.  Using Thumb instructions in the PLT
> > would give me some clearly measurable size improvements.
> 
> Would it really?  Here's an alternative: in the patches I'll be
> posting, I add support for independently sized PLT entries.  It would
> then be relatively simple (not trivial, because of relaxation problems,
> but doable) to use a two instruction ARM PLT sequence if it is in
> range.  The largest shared library I have handy at the moment has an
> 85K PLT using the new three-word entries, and the first word is
> _always_ redundant.  Then use interworking branches to get to the PLT.
> 
> I doubt you'll get a Thumb PLT sequence under eight bytes.

I don't know what the three-word PLT entry is.  By relaxation, do you
mean loading a GOT index into a register and then branching to the
symbol resolution routine?  That would work for the first 256 GOT
entries, and for some subset of the subsequent ones.  Or did you have
something else in mind?

The eight-byte Thumb sequence includes the offset word, and relies on
branching to common code to do the rest of the work.  I agree that it
is unlikely to get smaller than that.

Ian

  reply	other threads:[~2004-11-04 15:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-02 14:22 Paul Brook
2004-11-02 14:41 ` Richard Earnshaw
2004-11-02 15:12   ` Daniel Jacobowitz
2004-11-04  1:55     ` Ian Lance Taylor
2004-11-04 10:20       ` Richard Earnshaw
2004-11-04 14:19         ` Daniel Jacobowitz
2004-11-04 14:33           ` Richard Earnshaw
2004-11-04 15:10             ` Daniel Jacobowitz
2004-11-04 15:03         ` Ian Lance Taylor
2004-11-04 15:08           ` Daniel Jacobowitz
2004-11-04 15:42             ` Ian Lance Taylor [this message]
2004-11-04 15:49               ` Daniel Jacobowitz
2004-11-04 15:47           ` Richard Earnshaw
2004-11-04 16:01             ` Ian Lance Taylor
2004-11-02 15:06 ` Ian Lance Taylor

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=m33bzplixk.fsf@gossamer.airs.com \
    --to=ian@wasabisystems.com \
    --cc=binutils@sources.redhat.com \
    --cc=drow@false.org \
    --cc=paul@codesourcery.com \
    --cc=rearnsha@arm.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).