Re: [PATCH 2/3] Revert "[AArch64][BZ #17711] Fix extern protected data handling"

["maskray@google.com" <maskray@google.com>]

On 2022-05-25, Wilco Dijkstra wrote:
>Hi H.J.,
>
>> All imported symbols can be marked with the default visibility and all
>> exported symbols, in both executables and shared libraries, can be
>> marked with the protected visibility.   These require code changes.
>
>I meant doing this automatically using an option so most code requires no
>source changes. If commonly used libraries mark their exported symbols,
>most code (PIC, PIE and non-PIE) could be compiled using this option and
>produce efficient code without copy relocations and only using GOT
>indirections when needed (ie. accessing an exported symbol in another .so).
>It would also imply -fno-semantic-interposition for non-exported symbols.
>Currently there is no way to achieve this using options (eg. -fvisibility only
>affects definitions), and LLVM and GCC disagree on many details.
>
>Cheers,
>Wilco

Working out-of-the-box with -fpic and -fpie is trivial.
Working out-of-the-box with -fno-pic is not, as some code may rely on
the traditional codegen behavior that absolute resolutions are used.
I think the situation is worse on x86-32.

For protected data symbols, it's not a problem:

(a) Exported data symbols from shared object are rare. This is discouraged
as exported data symbols is part of ABI and makes DSO upgrading
difficult.

(b) Making exported data symbols exported is even rarer.

(c) In addition, many aarch64 OSes (Android, Chrome OS, FreeBSD, some
musl+llvm based Linux distributions, etc) use lld which does not allow
copy relocation on protected data symbols.
I haven't heard they have found any breakage due to the lld linker error.

(d) -fno-pic is out of favor now with the adoption of default -fpie.