public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@zembu.com>
To: drow@false.org
Cc: Franz.Sirl-kernel@lauterbach.com, binutils@sourceware.cygnus.com,
	geoffk@ozemail.com.au
Subject: Re: R_PPC_LOCAL24PC c++ linking problems with current binutils
Date: Mon, 19 Jul 1999 19:56:00 -0000	[thread overview]
Message-ID: <19990720014205.28842.qmail@daffy.airs.com> (raw)
In-Reply-To: <19990719205135.A642@drow.res.cmu.edu>

   Date: Mon, 19 Jul 1999 20:51:35 -0400
   From: Daniel Jacobowitz <drow@false.org>

   I don't claim to understand this section, but if it truly makes no
   sense to point a local relocation at a symbol not in _this object_,
   then perhaps it is not safe to generate 'bl symbol@local' when symbol
   is in a linkonce section?

I think it's OK, although I'm not completely certain.

Note that ``this object'' in this case means ``this executable'' or
``this shared library.''

My reading of the egcs code is that gcc will use @local if the symbol
is static, or if it has already emitted code for the function in
question.  It's unlikely that gcc will generate a linkonce section for
a static function, so most likely this is the case in which it has
already emitted code for the function.  In that case, the only time
the linkonce section will not be used is when there is another
linkonce section of the same name in the ``same object,'' which
implies that it provides the same function, and that @local is OK.

I do wonder if there is a bug in gcc when it comes to calling a weak
function.  It looks as though gcc will generate @local when calling a
weak function, but that is unsafe.  I expect it would break cases in
which non-PIC code is put into a shared library, an operation which is
odd but legal.

Ian

  reply	other threads:[~1999-07-19 19:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-19 15:21 Franz Sirl
1999-07-19 16:49 ` Ian Lance Taylor
1999-07-19 17:49   ` Daniel Jacobowitz
1999-07-19 19:56     ` Ian Lance Taylor [this message]
1999-07-19 20:07   ` Daniel Jacobowitz
1999-07-20  9:33     ` Ian Lance Taylor
1999-07-19 19:30 ` Geoff Keating
1999-07-19 20:05   ` Daniel Jacobowitz
1999-07-20  9:43   ` 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=19990720014205.28842.qmail@daffy.airs.com \
    --to=ian@zembu.com \
    --cc=Franz.Sirl-kernel@lauterbach.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=drow@false.org \
    --cc=geoffk@ozemail.com.au \
    /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).