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: binutils@sources.redhat.com
Subject: Re: RFA: Support for Thumb in dynamic objects
Date: Wed, 17 Nov 2004 03:42:00 -0000	[thread overview]
Message-ID: <m3mzxhp2ex.fsf@gossamer.airs.com> (raw)
In-Reply-To: <20041117030226.GA3884@nevyn.them.org>

Daniel Jacobowitz <drow@false.org> writes:

> > There is, of course, a second related issue, which is whether the
> > other objects involved in the dynamic link are compiled with
> > interworking support.  In my case I could not assume that.  So while
> > my linker doesn't add a stub for each R_ARM_THM_PC22 reloc--it just
> > changes those to blx when appropriate--it does automatically add a
> > stub for ABS32 and GOT32 references to Thumb code.  I don't have a
> > good automatic solution here--perhaps the new new ABI, which I gather
> > requires interworking support, will take the issue off the table.
> > 
> > Along similar lines it is quite easy for the linker to generate stubs
> > for all functions potentially referenced by non-interworking code, so
> > the need for the -mcallee-super-interworking option goes away.
> 
> I haven't done any work on the linker equivalents of super
> interworking, since I didn't need them at the time.  If you'd like to
> contribute it, of course... :-)

Of course, before I can contribute them, we have to work out the
issues of when you can use ARMv5T and when you can't assume
the code supports interworking....

(Of course the linker can only handle -mcallee-super-interworking.
-mcaller-super-interworking requires compiler support.  That was
unfortunately broken since it was written; I implemented my own
version, only to discover that it has been fixed in the current
compiler anyhow.  (Although I do wonder what happens with the current
compiler when using a shared libgcc and making a
caller-super-interworking call via ip.))

Ian

  reply	other threads:[~2004-11-17  3:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-16 23:39 Daniel Jacobowitz
2004-11-17  0:22 ` Paul Brook
2004-11-17  0:37   ` Daniel Jacobowitz
2004-11-17  1:37 ` Ian Lance Taylor
2004-11-17  3:02   ` Daniel Jacobowitz
2004-11-17  3:42     ` Ian Lance Taylor [this message]
2004-11-17 13:48 ` Richard Earnshaw
2004-11-17 16:49   ` Daniel Jacobowitz
2004-11-17 17:00     ` Richard Earnshaw
2004-11-17 17:05       ` Daniel Jacobowitz
2004-11-17 17:12         ` Richard Earnshaw
2004-11-17 17:36           ` Daniel Jacobowitz
2004-11-17 17:39             ` Richard Earnshaw

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