[RFC PATCH 2/2] arm64: kernel: switch to PIE code generation for relocatable kernels

[Fangrui Song]

On 2022-04-29, Ard Biesheuvel wrote:
>On Fri, 29 Apr 2022 at 09:03, Fangrui Song <maskray at google.com> wrote:
>>
>> On 2022-04-28, Ard Biesheuvel wrote:
>> >On Thu, 28 Apr 2022 at 20:53, Nick Desaulniers <ndesaulniers at google.com> wrote:
>> >>
>> >> On Wed, Apr 27, 2022 at 11:57 PM Fangrui Song <maskray at google.com> wrote:
>> >> >
>> >> > On 2022-04-28, Ard Biesheuvel wrote:
>> >> > >On Thu, 28 Apr 2022 at 04:40, Fangrui Song <maskray at google.com> wrote:
>> >> > >>
>> >> > >> On 2022-04-27, Ard Biesheuvel wrote:
>> >> > >> >Fortunately, we can convince the compiler to handle this in a way that
>> >> > >> >is a bit more suitable for freestanding binaries such as the kernel, by
>> >> > >> >setting the 'hidden' visibility #pragma, which informs the compiler that
>> >> > >> >symbol preemption or CoW footprint are of no concern to us, and so
>> >> > >> >PC-relative references that are resolved at link time are perfectly
>> >> > >> >fine.
>> >> > >>
>> >> > >> Agree
>> >> > >>
>> >> > >
>> >> > >The only unfortunate thing is that -fvisibility=hidden does not give
>> >> > >us the behavior we want, and we are forced to use the #pragma instead.
>> >> >
>> >> > Right. For a very long time there had been no option controlling the
>> >> > access mode for undefined symbols (-fvisibility= is for defined
>> >> > symbols).
>> >> >
>> >> > I added -fdirect-access-external-data to Clang which supports
>> >> > many architectures (x86, aarch64, arm, riscv, ...).
>> >> > GCC's x86 port added -mdirect-extern-access in 2022-02 (not available on aarch64).
>> >> >
>> >> > The use of `#pragma GCC visibility push(hidden)` looks good as a
>> >> > portable solution.
>> >>
>> >> Portable, sure, which is fine for now.
>> >>
>> >> But there's just something about injecting a header into ever TU via
>> >> -include in order to set a pragma and that there's such pragmas
>> >> effecting codegen that makes my skin crawl.
>> >>
>> >> Perhaps we can come up with a formal feature request for toolchain
>> >> vendors for an actual command line flag?
>> >>
>> >> Does the pragma have the same effect as
>> >> `-fdirect-access-external-data`/`-mdirect-extern-access`, or wvisould
>> >> this feature request look like yet another distinct flag?
>>
>> `#pragma GCC visibility push(hidden)` is very similar to
>> -fvisibility=hidden -fdirect-access-external-data with Clang.
>> In Clang there are only two differences:
>>
>>    // TLS initial-exec model with -fdirect-access-external-data;
>>    // TLS local-exec model with `#pragma GCC visibility push(hidden)`
>>    extern __thread int var;
>>    int foo() { return var; }
>>
>>    // hidden visibility suppresses -fno-plt.
>>    // -fdirect-access-external-data / GCC -mdirect-extern-access doesn't suppress -fno-plt.
>>    extern int bar();
>>    int foo() { return bar() + 2; }
>>
>>
>> The kernel uses neither TLS nor -fno-plt, so -fvisibility=hidden
>> -fdirect-access-external-data can replace `#pragma GCC visibility
>> push(hidden)`.
>>
>
>OK. But you mentioned that GCC does not implement
>-mdirect-extern-access for AArch64, right? So for now, the pragma is
>the only portable option we have.

Right.

>> >I agree that this is rather nasty. What I don't understand is why
>> >-fvisibility=hidden gives different behavior to begin with, or why
>> >-ffreestanding -fpie builds don't default to hidden visibility for
>> >symbol declarations as well as definitions.
>>
>> -ffreestanding doesn't mean there is no DSO. A libc implementation (e.g.
>> musl) may use -ffreestanding to avoid libc dependencies from the host
>> environment. It may ship several shared objects and export multiple symbols.
>> Implied -fvisibility=hidden will get in the way.
>>
>> There is a merit to make options orthogonal.
>
>Fair enough.