From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11991 invoked by alias); 22 Feb 2016 23:14:02 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 11838 invoked by uid 89); 22 Feb 2016 23:14:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=among X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qk0-f182.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=za5STSHkgV+3Oa5XAGdrzgBArx9LeV6xsUHKz7tDKzg=; b=AMdY+Uma+wCmIsbfDYKHTjmNU/PClmQ6y3Ow7glnvqCUdSlNDVzz/17xcsyyjzA9qJ 7Prn3+QV64RdHwTpjk4SumwJhJH3NmMmMr2kQxV5va+lafZQJEOsHWWSj47M8/g6WZgO mCRl6qzd3YA38D+OLVpjtN9Tv0Xx4f66iNSfDqqmFtrcRV9hR/fsbLEk4Se6xd8URXGQ II2bCRVIZpHXHbMljJd09jiFtLg6Z5kIGxC2uX9H4ygxjirVIGiViILGcRCjYC3XPVTk IGxF+c+zy9LNUPHRy4bJbWIlDJbrWd+Wkl6YrQHgfFGem1IgNpmx4YFmXybHMrRy7Qht ehWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=za5STSHkgV+3Oa5XAGdrzgBArx9LeV6xsUHKz7tDKzg=; b=RL/p75dQaPmRfPJPtWPT5+ECxrT/zrzgfcGdLb4RsYPWy1L1jl9NRZ+DqQLlsZygBn jtthX8QGGNWzPCu97hX4d9lY5T0HLthT7QgcYEHHLun6N4X2OHmXIwBJCJHw8F3RDfT8 cTwr1J9ZeJcObEr474HKvCNKm8agmOPWrBD8izgs9ky8Kond6HYf/xwlZhXoX1AemuwJ /KwKxglnbbkq8Vp2DhX2ZJ87NUOBZ2J3VXMKN0XNKRWtz7YZdhRQsHAAvhRq7sllvjhu Y07dL9foAZv2pECLETFS6Zb6K7pi7S+ZPZrfpmD6BwNjjKkROo10unDO2k9W7NhveX1E ncHg== X-Gm-Message-State: AG10YOQKuXDZqE9cicdVT3neHo0k2jwHiUh5lnEFSkcTpV2wI+29h+XF6sjn0yvERwlPOZ0UaRU2TwK09DaLiw== MIME-Version: 1.0 X-Received: by 10.55.76.15 with SMTP id z15mr37860606qka.32.1456182836425; Mon, 22 Feb 2016 15:13:56 -0800 (PST) In-Reply-To: References: Date: Fri, 01 Jan 2016 00:00:00 -0000 Message-ID: Subject: Re: Specify how undefined weak symbol should be resolved in executable From: "H.J. Lu" To: Michael Matz Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q1/txt/msg00013.txt.bz2 On Mon, Feb 22, 2016 at 2:47 PM, H.J. Lu wrote: > On Mon, Feb 22, 2016 at 2:43 PM, H.J. Lu wrote: >> On Mon, Feb 22, 2016 at 10:28 AM, H.J. Lu wrote: >>> On Mon, Feb 22, 2016 at 10:17 AM, Michael Matz 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
: >> 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 >> a: 48 83 ec 08 sub $0x8,%rsp >> e: e8 00 00 00 00 callq 13 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.