Re: [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 22 August 2017 at 14:27, Paolo Bonzini <pbonzini@redhat.com> 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.