[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Specify how undefined weak symbol should be resolved in executable



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?

-- 
H.J.