public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Michael Matz <matz@suse.de>
Cc: Alan Modra <amodra@gmail.com>, gnu-gabi@sourceware.org
Subject: Re: Specify how undefined weak symbol should be resolved in executable
Date: Fri, 01 Jan 2016 00:00:00 -0000	[thread overview]
Message-ID: <CAMe9rOp4OO8AWo0gxLqa+XeUOCQrHqYrXwRz_CfBU4PfKBWsww@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOpQ4Fwk7wJNQuW_5VFuZTApuixt5e=NdrUmZccYK17cCg@mail.gmail.com>

On Tue, Feb 23, 2016 at 9:10 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 9:01 AM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Tue, 23 Feb 2016, H.J. Lu wrote:
>>
>>> >> Not only we need to change defined weak symbol behavior, we also need
>>> >> to change undefined non-weak symbol behavior when taking its address.
>>> >
>>> > Why?  An undefined non-weak symbol reference leads to a linker error,
>>> > done.  Why change that?
>>>
>>> Make it "external non-weak symbol", which is a symbol defined in a
>>> shared object.
>>
>> What would you like to change in behaviour for them (and why must it be
>> done at the same time as changing something for weak symbols)?  A
>> reference to the address of such a function symbol from an executable
>> resolves to the plt slot currently (which in turn is exported, so that
>> address references from other modules resolve to the same).  A reference
>> to a non-function symbol is loaded from the got.  In all cases must this
>> symbol be defined somewhere (otherwise linker error), so I don't see what
>> we need to change, nor why that would force DT_TEXTREL (or the compiler to
>> emit PIC like code).
>>
>
> At run-time, there is no difference between weak defined and non-weak
> defined symbols.  If we change defined weak symbol behavior, we also
> need to change defined non-weak symbol behavior.
>

I will check this patch:

https://sourceware.org/ml/binutils/2016-02/msg00339.html

into binutils master branch to make behaviors of static executable,
dynamic executable and position independent executable consistent with
references to undefined weak and defined symbols, regardless if the
relocatable input is compiled with PIC or not.

I created users/hjl/pr19704 branch to treat undefined weak symbol in
the executable as dynamic, requiring dynamic relocation, on x86 via
a command line switch:

-z dynamic-undefined-weak   Treat undefined weak symbol as dynamic

We need to fully investigate its implications before moving forward
with it.

-- 
H.J.

  reply	other threads:[~2016-02-23 18:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-01  0:00 H.J. Lu
2016-01-01  0:00 ` H.J. Lu
2016-01-01  0:00   ` Michael Matz
2016-01-01  0:00     ` H.J. Lu
2016-01-01  0:00       ` Michael Matz
2016-01-01  0:00         ` H.J. Lu
2016-01-01  0:00           ` H.J. Lu
2016-01-01  0:00             ` H.J. Lu
2016-01-01  0:00               ` H.J. Lu
2016-01-01  0:00             ` Alan Modra
2016-01-01  0:00               ` H.J. Lu
2016-01-01  0:00                 ` Michael Matz
2016-01-01  0:00                   ` H.J. Lu
2016-01-01  0:00                     ` Michael Matz
2016-01-01  0:00                       ` H.J. Lu
2016-01-01  0:00                         ` H.J. Lu [this message]
2016-01-01  0:00                         ` Alan Modra
2016-01-01  0:00                           ` H.J. Lu
2016-01-01  0:00                             ` Alan Modra
2016-01-01  0:00                               ` Carlos O'Donell
2016-01-01  0:00                                 ` H.J. Lu
2016-01-01  0:00                                   ` Michael Matz
2016-01-01  0:00                                     ` H.J. Lu
2016-01-01  0:00                                       ` Michael Matz
2016-01-01  0:00                                         ` H.J. Lu
2016-01-01  0:00                                           ` Michael Matz
2016-01-01  0:00                                             ` H.J. Lu
2016-01-01  0:00               ` H.J. Lu
2016-01-01  0:00                 ` Michael Matz
2016-01-01  0:00                   ` H.J. Lu
2016-01-01  0:00                     ` Michael Matz
2016-01-01  0:00                       ` Szabolcs Nagy
2016-01-01  0:00                         ` Michael Matz
2016-01-01  0:00   ` H.J. Lu

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=CAMe9rOp4OO8AWo0gxLqa+XeUOCQrHqYrXwRz_CfBU4PfKBWsww@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=amodra@gmail.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=matz@suse.de \
    /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).