From: "H.J. Lu" <hjl.tools@gmail.com>
To: Michael Matz <matz@suse.de>
Cc: 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: <CAMe9rOr+fs0hBg2wE8CJo69CjcDzOcrJ2bXjCEfREyK=ok1nzw@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOq=VrVO4b9fJFMB0ZfzAWPMDbCC+FEW0geCzd_Ju0aqoA@mail.gmail.com>
On Mon, Feb 22, 2016 at 2:47 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 2:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Feb 22, 2016 at 10:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Mon, Feb 22, 2016 at 10:17 AM, Michael Matz <matz@suse.de> wrote:
>>>> Hi,
>>>>
>>>> On Mon, 22 Feb 2016, H.J. Lu wrote:
>>>>
>>>>> > Typo? What is the meaning of "dynamic relocation available at
>>>>> > runtime". Are you talking about a relocation entry or the relocation
>>>>> > process?
>>>>>
>>>>> Dynamic relocation isn't available with static linking.
>>>>
>>>> So you _are_ talking about the process. I think it's customary to call
>>>> such executables "dynamic", or perhaps non-static, isn't it? (Why I'm
>>>> confused with your wording: a dynamic executable which happens to have no
>>>> dynamic reloc entries, has "no dynamic relocation available at runtime",
>>>> and so we couldn't add one :))
>>>>
>>>>> > How about "When creating a dynamic executable the link editor should
>>>>> > ..."?
>>>>
>>>> So, I still can understand my version better (possibly with
>>>> s/dynamic/non-static/) :)
>>>>
>>>
>>> Let's go with:
>>>
>>> When creating dynamic executable, the link editor should generate dynamic
>>> relocations against unresolved weak symbols so that their values will be
>>> resolved at run-time.
>>>
>>
>> Second thought. To generate dynamic relocation for R_X86_64_32
>> against fun in:
>>
>> [hjl@gnu-6 pr19704]$ objdump -dwr foo.o
>>
>> foo.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text.startup:
>>
>> 0000000000000000 <main>:
>> 0: b8 00 00 00 00 mov $0x0,%eax 1: R_X86_64_32 fun
>> 5: 48 85 c0 test %rax,%rax
>> 8: 74 10 je 1a <main+0x1a>
>> a: 48 83 ec 08 sub $0x8,%rsp
>> e: e8 00 00 00 00 callq 13 <main+0x13> f: R_X86_64_PC32 fun-0x4
>> 13: 31 c0 xor %eax,%eax
>> 15: 48 83 c4 08 add $0x8,%rsp
>> 19: c3 retq
>> 1a: 31 c0 xor %eax,%eax
>> 1c: c3 retq
>> [hjl@gnu-6 pr19704]$
>>
>> we create executable with dynamic R_X86_64_32 relocation against
>> fun .text section, which leads to DT_TEXTREL. Is this what we want?
>>
>
> I believe the intention of undefined weak symbol is it should be resolved
> at link-time when creating executable, dynamic or static.
There is discrepancy between PIC input and non-PIC input on x86.
There may be a discrepancy between x86, where PIC is off by default,
and the target, where PIC is always on. If we can't get an agreement
among Linux targets, we should address it in x86 psABI.
--
H.J.
next prev parent reply other threads:[~2016-02-22 23:14 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 [this message]
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 ` 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 ` 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='CAMe9rOr+fs0hBg2wE8CJo69CjcDzOcrJ2bXjCEfREyK=ok1nzw@mail.gmail.com' \
--to=hjl.tools@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).