From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F3F742095B9C8 for ; Tue, 22 Aug 2017 07:00:44 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id o196so16169179ioe.0 for ; Tue, 22 Aug 2017 07:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Te4ubyAAALnL7cUT/LUToEmXTtjhmdaNv72dtDrEgno=; b=TO61e8ESpA9a22R5yLaxs7L8htQuyQo6PbCZj+aGRFCfJOwe/FHnmBFbf9MOsESeZL LSUKnEb16ZQdHAayiGCh0d3d96SSK+MKl1vg9wxnl892h7iq0IMe9NCo9wScJhBim9NP EFQw/TM087i9JVJStSVtr1/ohHhRMjh0UNxkk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Te4ubyAAALnL7cUT/LUToEmXTtjhmdaNv72dtDrEgno=; b=WUpGCItnLxzF+tRcTPajNBtiwDzxSqzaO/IHntNRNtUBlAtCJVVUlyvjsyWIcX1kry 9cmSLpMzdb6YrORbRh/rOJcCLh+XBAr3ppe+l69egV2dhcsXFQk3UpF/ABFsPP/pgK6+ cdomcZZtf0+O6ZqXhuMkYcBzOJ1vq00QeMdSwcb78gUZt77JFRa6B5zbWqV0BscBWl6k IVUkmzStvj2+IhvOnDOMhXVyCgEtpf4wJ1urqbj5uGhmdKvDpVS1rdVsvgb41URFVgNJ rSHkX2Ng+2blKpTuIdem2h9e9vehkN5oB3Ne1p46GkG5p4okGqkIDzlKmEeCd/EGu5g3 2KOw== X-Gm-Message-State: AHYfb5jewlwfSe3t+ZbKDXS0xYQ+AN14JXknEL7lc9Rcrog6PVohkHV4 IvIWv+NW6+NkNSEAdqUW2U3Pypjzifc5 X-Received: by 10.107.46.234 with SMTP id u103mr644412iou.192.1503410593291; Tue, 22 Aug 2017 07:03:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.1 with HTTP; Tue, 22 Aug 2017 07:03:12 -0700 (PDT) In-Reply-To: References: <20170811003426.2332-1-lersek@redhat.com> <20170811003426.2332-2-lersek@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B560EB2@shsmsx102.ccr.corp.intel.com> <787f4528-980e-8c71-2804-0e8be2c935aa@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B56176B@shsmsx102.ccr.corp.intel.com> <092446e6-0900-7eb3-d071-b88abcdadfa9@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B5673A1@shsmsx102.ccr.corp.intel.com> <3c593a67-bffc-45db-e65c-8d0242ddada4@redhat.com> From: Ard Biesheuvel Date: Tue, 22 Aug 2017 15:03:12 +0100 Message-ID: To: Paolo Bonzini Cc: Laszlo Ersek , "Shi, Steven" , edk2-devel-01 , Alex Williamson , "Justen, Jordan L" , "Gao, Liming" , "Kinney, Michael D" Subject: Re: [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 14:00:45 -0000 Content-Type: text/plain; charset="UTF-8" On 22 August 2017 at 14:27, Paolo Bonzini wrote: > On 22/08/2017 13:59, Laszlo Ersek wrote: >> This seems to suggest that "-pie" is the *master* switch (used only when >> linking), and "-fpie" is a *prerequisite* for it (to be used both when >> linking and compiling). Is this right? >> >> If so, then I think this is a gcc usability bug. We don't generally >> start our thinking from the linker side. The above implies that the >> simple (hosted) command line: >> >> $ gcc -o example -fpie source1.c source2.c >> >> could also result in miscompilation, because "-pie" is not given, only >> "-fpie". > > No, GCC should add -pie on its own. > I disagree. PIE linking and PIE code generation are two completely different things. PIE linking (in the absence of LTO) only involves emitting the sections containing the metadata required by the loader at runtime. Because dynamic ELF relocations are more restricted than static ones, and only operate on native pointer sized quantities, this imposes constraints on the code generation, which is why we need the -fpic or -fpie compiler switch. On ARM, this means you should not emit absolute symbol references where the address is encoded in the immediate field of a sequence of movw/movt/movz/movk instructions. I'm sure there are similar restrictions on other architectures. Note that the arm64 KASLR kernel does use PIE linking but omits -fpic/-fpie simply because the default small code model never uses such instructions, but always uses relative references (and statically initialized function pointers etc are guaranteed to be dynamically relocatable) IIRC, PIE linking predates the availability of the -fpie GCC flag, and so -fpic objects were used to create PIE binaries, because they happened to fulfil these requirements, given that they apply to shared libraries as well. However, -fpic is geared towards ELF symbol preemption and other restrictions that do apply to shared libraries but not to PIE executables, and so the -fpie switch was introduced as an alternative, which generates code that may not be suitable for a shared library but can be used in a PIE or ordinary executable. None of this really applies to bare metal binaries, which is why we need the visibility tweaks when using -fpic/-fpie, in which case the compiler will relative references over absolute ones. Such objects could be combined in different ways, and PIE linking is only one of them.