From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id C436F3896C0E for ; Tue, 23 Feb 2021 13:32:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C436F3896C0E Received: by mail-ot1-x32b.google.com with SMTP id s107so15513551otb.8 for ; Tue, 23 Feb 2021 05:32:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mYylSoh55ebK1e3QMINSpoDc7RY/u7TAz2LYnzNb5nM=; b=s2ZZ7l0/tVZNE7MJHo5nqt9I9D82/dyjh/dHBgqa+SmO07ahWdEina0goSnRwGST+O is1MflZcoq1KIhzJwPPTw9Agq1668UuxHKeFh6cKry+i+nag76mktX4gn7T3OkBmyvcG 61LNZzVTF6DyPfbXBfQErOt7FXCncEr7BCEyddL6+OX09rBT2uXY59KfYQQ1y/cS0mxY ENwvgLNkwdGElEXNaYMu8UWQ5Gsr/cPxUKzhM1xk0xiXmvNXGabuah77y5vmVOMkF6DV Kfoi44CgNTjIMqHW0mCZdV9lys0GqMAtixJSd5PlkZ+KZTAZ7fNLqMEc5elVy8XDouct QfYQ== X-Gm-Message-State: AOAM530ex4dqi3E72lsVNa4bJHak+CjbiDYXjJqYtpqZANK4HQR1bjcd JDSukmJEpbxvwtoL6UhOmWGxvLOtSyJo2eH/JIH9GS0YBbU= X-Google-Smtp-Source: ABdhPJy21e2lARgCPXcIZA4Z4D7wLt+cqZNBFda3jPPRPNn/fy0zpcQJdqPsqomXqjsclBTD4SCTeGp3TfmHEugdfB8= X-Received: by 2002:a9d:bcb:: with SMTP id 69mr20152248oth.269.1614087124263; Tue, 23 Feb 2021 05:32:04 -0800 (PST) MIME-Version: 1.0 References: <20210223121558.3529429-1-hjl.tools@gmail.com> <77fa2de7-91ad-5f33-ea60-91c097d1c8ff@suse.com> In-Reply-To: <77fa2de7-91ad-5f33-ea60-91c097d1c8ff@suse.com> From: "H.J. Lu" Date: Tue, 23 Feb 2021 05:31:28 -0800 Message-ID: Subject: Re: [PATCH] elf/x86-64: Subtract __ImageBase for R_AMD64_IMAGEBASE To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 13:32:06 -0000 On Tue, Feb 23, 2021 at 5:15 AM Jan Beulich wrote: > > On 23.02.2021 13:15, H.J. Lu via Binutils wrote: > > When linking PE/x86-64 inputs to generate ELF executable, we need to > > subtract __ImageBase, aka __executable_start, for R_AMD64_IMAGEBASE > > relocation. > > Do you really mean PE/x86-64, not the respective COFF objects? In the What is the difference? How should I call object files generated by Microsoft Visual Studio? > description this may not matter much, but since there's at least one > code comment also saying so, which may confuse readers, I'd like to > understand this. > > Also, in how far is this x86-64-specific? I don't know. > > --- a/ld/testsuite/ld-x86-64/pe-x86-64-1.od > > +++ b/ld/testsuite/ld-x86-64/pe-x86-64-1.od > > @@ -2,6 +2,7 @@ > > .*: +file format .* > > > > SYMBOL TABLE: > > +0+400000 g .text\$mn 0000000000000000 __executable_start > > 0+401000 g .text\$mn 0000000000000000 getaddr1 > > 0+401020 g .text\$mn 0000000000000000 begin > > 0+403014 g .bss 0000000000000000 __bss_start > > I don't think this artifical symbol should appear in the symbol This symbol is generated by linker. It should be harmless. > table. I also wonder what the consequences are if a set of linked > object files specifies a symbol of this name. __executable_start is generated by linker. If __ImageBase is defined to another value, that value will be used as image base. -- H.J.