From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110045 invoked by alias); 22 Feb 2016 22:47:09 -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 110022 invoked by uid 89); 22 Feb 2016 22:47:09 -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.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2177 X-Spam-Status: No, score=-2.4 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-qg0-f52.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=DEwlME4j8WhqkMpg4gd/2+lWUiQjJ/GjL5943C7Q5oo=; b=mhrT6jJ9dA2Gx79DL6B7F282mxoWmpAbca3pt2UbSeFlLqSiy46rP64io9KTb1Ao/U bwoSV5txfDVwAnxNr9RwLU/re1pUzWQsVQTOM2F2S9lG/Osus7JROUXwb4XCj1Ptondl i/aXXyvaGA4v3DTDuUvfBDDWOmKCIob1vwj/GHE0pOtN3/2/CcsT05+6PQ42HlNXg+lP w2JcP10qD49farxNQGvhYbm81hYXE7NqGI7+teu7AskvjqxSrPykwwcXrn3H4Zy1oict 8IhIvX26Bwq1zyjwCVstRX8tpC1Gmel7KpUTLGdX+lG+lyOh1I04TAYeMeYIbaVwmHBl k8wA== 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=DEwlME4j8WhqkMpg4gd/2+lWUiQjJ/GjL5943C7Q5oo=; b=DazQOIIZ8JPWvNlrl9mRyQVKqsbutg28ai0NGBnGJNf5I5ECK/OJCd6plV97hEPC03 HU9/uxzfzY5Y2hR/rgNLAMQXTfJKSU7VuqL2kOebUKFkiiqksv55Xiuz1sF9IXweMCPG a75NHWYqYilKjIVJ661qrK3EKDa/s7VjgZcOQm5djRRbT6HXAGOGYwht9UeXpgEI3OrS Y+0mFRI9UNOSkb93onu1robF1NbKDSk9bvMiPGhheVrRqDoC6e7BAslFVsfVAYA6Hms2 lAiJhQC2vfsVwXn50RmyzrHBUvOKtfmO9MnAEe86yzMd5B0FsUOOBjnLTr3PSYjSOx5D PgQg== X-Gm-Message-State: AG10YOR0FWIz9NJrSZWrR73tLBX5owwfgY+cGe0hB9MyY9K1oXdJWZ2gzu4Hyez16AhaRyk7q1RWLSlEw3S+ZQ== MIME-Version: 1.0 X-Received: by 10.140.169.9 with SMTP id p9mr39969161qhp.50.1456181225911; Mon, 22 Feb 2016 14:47:05 -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/msg00012.txt.bz2 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. -- H.J.