public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@airs.com>
To: Richard Earnshaw <rearnsha@gcc.gnu.org>
Cc: Julian Brown <julian@codesourcery.com>,
	Daniel Jacobowitz <drow@false.org>,
	binutils@sources.redhat.com
Subject: Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS
Date: Wed, 16 Mar 2005 17:16:00 -0000	[thread overview]
Message-ID: <m3r7if4kb3.fsf@gossamer.airs.com> (raw)
In-Reply-To: <1110990497.19581.51.camel@pc960.cambridge.arm.com>

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:

> On Wed, 2005-03-16 at 16:10, Ian Lance Taylor wrote:
> > Julian Brown <julian@codesourcery.com> writes:
> > 
> > > Would it be better to add a --target-arch (or something) flag to
> > > binutils at this point? That would tidy up a previous patch of mine,
> > > too. I don't know if any other targets have, or need, such an option.
> > 
> > I think the linker should support a command line option to do what
> > OUTPUT_ARCH does in a linker script.  
> 
> I'm not convinced, but then I'm not entirely sure what OUTPUT_ARCH
> does.  
> 
> It appears that OUTPUT_ARCH uses bfd variant names, but the problem is
> that in the past this has worked by (ab)using bits in the ELF header
> which simply aren't available in the EABI.  There's also a potential
> disaster in this area of the exploding cross-product: the core
> architecture is just one dimension in the matrix.

OUTPUT_ARCH lets you specify an architecture.  For ARM, this will be
one of the entries found in arch_info_struct in bfd/cpu-arm.c.  Of
course that list can be adjusted.

I think the ELF header issue is irrelevant here.  That is a matter of
how the architecture is represented in the output file.  It's
obviously convenient to represent the architecture correctly in the
output file so that it can be recognized by something reading the
file, but that is not a requirement, and the information does not have
to be in the ELF header.

> > Perhaps the thing to do would be
> > to redefine the -A/--architecture option, which is only used for the
> > Intel i960.  -A currently affects library search order, which we would
> > not want for the new option.    However, I doubt that anybody uses the
> > i960 any more, and even if they do, they probably don't use the -A
> > option.
> 
> I'd really like to be able to just pass -march through from the
> compiler.  Anything solution that needs any remapping beyond a common
> prefix substitution in a gcc spec file is just a disaster waiting to
> happen.

The linker already has a -m option, used to specify the emulation to
use, so -march itself would not work.  But I wouldn't be opposed to
adding an option which just set the machine name.  I would have to be
convinced about adding something which bypassed the existing BFD
architecture/machine machinery.

Ian

  reply	other threads:[~2005-03-16 16:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-16 14:52 Julian Brown
2005-03-16 14:56 ` Richard Earnshaw
2005-03-16 15:27   ` Daniel Jacobowitz
2005-03-16 16:10     ` Julian Brown
2005-03-16 16:29       ` Richard Earnshaw
2005-03-16 16:34         ` Julian Brown
2005-03-16 16:42       ` Ian Lance Taylor
2005-03-16 16:54         ` Richard Earnshaw
2005-03-16 17:16           ` Ian Lance Taylor [this message]
2005-03-16 17:34             ` Richard Earnshaw
2005-03-16 22:00               ` Ian Lance Taylor
2005-03-17  0:13                 ` Richard Earnshaw
2005-03-18 19:59                   ` Julian Brown
2005-03-17 20:58           ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Julian Brown
2005-03-17 21:03             ` Question! NK
2005-03-23 20:11               ` Question! Nick Clifton
2005-03-17 21:25             ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Paul Brook
2005-03-16 16:16     ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 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=m3r7if4kb3.fsf@gossamer.airs.com \
    --to=ian@airs.com \
    --cc=binutils@sources.redhat.com \
    --cc=drow@false.org \
    --cc=julian@codesourcery.com \
    --cc=rearnsha@gcc.gnu.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).