public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@gcc.gnu.org>
To: Ian Lance Taylor <ian@airs.com>
Cc: Julian Brown <julian@codesourcery.com>, binutils@sources.redhat.com
Subject: Re: [PATCH] Indicate dependency on personality routines for ARM EHABI
Date: Wed, 09 Feb 2005 17:28:00 -0000	[thread overview]
Message-ID: <1107967723.4376.9.camel@pc960.cambridge.arm.com> (raw)
In-Reply-To: <m3hdkllmme.fsf@gossamer.airs.com>

On Wed, 2005-02-09 at 16:32, Ian Lance Taylor wrote:
> Julian Brown <julian@codesourcery.com> writes:
> 
> >   /* These relocs are only used within the ARM assembler.  They are not
> >   (at present) written to any object files.  */
> > +   BFD_RELOC_ARM_NONE,
> 
> Why not just use BFD_RELOC_NONE here?
> 

Ah!  Good point

> In general you should only create a target specific BFD_RELOC enum
> constant for relocations which only arise on a particular target.  For
> example, note that there is no BFD_ARM_RELOC_32.
> 
> More generally, I think it's kind of dubious to use a zero reloc to
> mean anything at all.  And why do you need a relocation entry?  Why is
> it not sufficient to enter the symbol in the symbol table as an
> undefined symbol?  Is the use of a zero reloc mandated by the ARM ABI?

Because the unwind module only weakly links to the personality modules
(but it is the one that ends up calling them).

The module that needs the unwinding has to provide the strong reference
to ensure that it gets included in the link set.

Doing it this way ensures that only personality modules that are needed
get included in the final image.

R.

  parent reply	other threads:[~2005-02-09 16:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-09 17:06 Julian Brown
2005-02-09 17:09 ` Ian Lance Taylor
2005-02-09 17:24   ` Paul Brook
2005-02-09 17:32     ` Ian Lance Taylor
2005-02-09 19:43     ` Andreas Schwab
2005-02-09 17:28   ` Richard Earnshaw [this message]
2005-02-09 17:42     ` Ian Lance Taylor
2005-02-09 18:26       ` Richard Earnshaw
2005-02-09 19:02   ` Julian Brown
2005-02-09 20:27     ` Ian Lance Taylor
2005-02-09 20:35     ` Richard Earnshaw
2005-02-09 21:48       ` Julian Brown
2005-02-09 22:21       ` Julian Brown
2005-02-10 14:07         ` Richard Earnshaw
2005-02-09 17:12 ` 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=1107967723.4376.9.camel@pc960.cambridge.arm.com \
    --to=rearnsha@gcc.gnu.org \
    --cc=binutils@sources.redhat.com \
    --cc=ian@airs.com \
    --cc=julian@codesourcery.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).