In D154045#4656377, @efriedma wrote:

Looking at the discussion of initialization, was there any consideration of lazily initializing the "__aarch64_has_sme_and_tpidr2_el0" bit? I mean, I see an explanation for why the bit is cached, but I don't see any constraint on when that computation happens.

In D154045#4652199, @rsandifo-arm wrote:

A streaming-compatible function that calls printf (say) must force PSTATE.SM to 0 before the call and then restore it to its original value after the call. To do that, it needs to read the current PSTATE.SM. But in general, streaming-compatible functions are agnostic not just about whether the processor is in streaming mode, but also about whether SME is present at all. E.g. it's possible to compile a streaming-compatible function with base -march=armv8-a (without even SVE).

In D80791#2210207, @chill wrote:

In D80791#2210124, @danielkiss wrote:

it is not useful to have a bti annotated function unless everything else is bti compatible too: it is all or nothing per elf module.

This is false. Some functions in an elf module could be in a guarded region, some in a non-guarded region. Some function may always
be called in a "BTI-safe" way, which may be unknown to the compiler.

Right now the elf and all of the text sections considered BTI enabled or not. The dynamic linkers/loaders can't support this
use case without additional information to be encoded somewhere (and specified). To support such we need to consider grouping/align to page
boundaries these functions in the linker because BTI could be controlled by flags in PTE.
With the current spec this usecase is not supported in this way. The user have to link the BTI protected code into another elf.
Side note: The force-bti linker option can't work with half BTI enabled objects.

I suppose this is valid for typical Linux-based systems today.

Is it valid in general, across the whole spectre of operating systems or for bare-metal targets?

Guess not.

In D80791#2209703, @chill wrote:

In D80791#2209624, @nsz wrote:

• it is not useful to have a bti annotated function unless everything else is bti compatible too: it is all or nothing per elf module.

This is false. Some functions in an elf module could be in a guarded region, some in a non-guarded region. Some function may always
be called in a "BTI-safe" way, which may be unknown to the compiler.

In D80791#2207203, @chill wrote:

I would prefer to avoid the situation where the markings of two otherwise identical files were different,
depending on how the files were produced, no matter if it was a common or a special case.

In D80791#2206933, @chill wrote:

In D80791#2206853, @nsz wrote:

i think that cannot work.

the implementation is free to inject arbitrary code into
user code so if the user does not tell the implementation
that it wants the entire tu to be bti safe then non-bti
code can end up in there. (e.g. ctor of an instrumentation
that is not realated to any particular function with the
bti marking)

Certainly, there are cases it won't work, but there are definitely
cases where it *can* work. Whatever the implementation does
should be a deterministic consequence of implementing the relevant
language standards together with implementation-defined behaviour,
command-line options and language extensions (e..g attributes).

Certainly I don't expect C++ ctorts/dtors in C code and gcov or
sanitiser calls if I haven't given relevant -fprofile-whatever/-fsanitize=whatever
options. In that sense, the implementation cannot do whatever
it pleases, it is constrained to a range of behaviours one can reason about.

The 08/10/2020 10:03, Momchil Velikov via Phabricator wrote:

chill added a comment.

In D80791#2196598 https://reviews.llvm.org/D80791#2196598, @nsz wrote:

the assumption is that the intended branch protection is implied via cmdline flags for the tu and function attributes are only used in source code for some hack.

I don't share this assumption. I find it just as valid to control the PAC/BTI with things like:

#ifdef ENABLE_BTI
#define BTI_FUNC __attribute__((target("branch-protection=bti")))
#else
#define BTI_FUNC

BTI_FUNC void foo() { ...
BTI_FUNC int bar() { ...

without using any command-line option other than -DENABLE_BTI=1.

the gcc behaviour is not exactly ideal, but it's better if llvm is compatible with it or fix gcc if something is broken there.

In D72222#1837536, @MaskRay wrote:

A -DLLVM_ENABLE_ASSERTIONS=on build is required to trigger the assertion failure. My make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- HOSTGCC=gcc CC=~/llvm/ReleaseAssert/bin/clang LD=~/llvm/ReleaseAssert/bin/ld.lld O=/tmp/arm64 allmodconfig all -j 30 build succeeded. Now I will be in favor of pushing the bugfix to release/10.x .

Not clear about -fpatchable-function-entry=N,M where M>0 (D73070, D73071, D73072). For completeness, I'd like them to be included in release/10.x so we will not have a clang 10 that does not work with M>0.

For BTI c issue, GCC has several releases that do not work with -mbranch-protection=bti. The Linux kernel has to develop some mechanism to detect the undesirable placement of bti c, if there are -mbranch-protection=bti users. So I don't think that inconsistency in clang 10.0.0 with GCC will be a problem.

In D64930#1597590, @peter.smith wrote:

Will be worth mentioning that this is dependent on D64906 and D64903, I could guess at D64903 but basic-aarch64.s didn't apply cleanly without D64903. I successfully did a 2 stage bootstrap of clang with ninja check-all on a native aarch64 machine and made a quick test to check the TP relative relocation. I struggled a bit to understand the description and the comments though. In particular the use of GAP_ABOVE_TP instead of TCB_SIZE, it also wasn't clear where the alignment calculation had come from. I've made a few suggestions.

In D63863#1589031, @simon_tatham wrote:

Would some kind of architectural extension be a reasonable solution? -march=armv8+oldcoprocessors, or some such? That way -march=armv8 continues to diagnose things that actually are illegal in the architecture you asked for.

In D63863#1588965, @simon_tatham wrote:

Hmmm. This surely can't be the first time a case like this has come up. What's the usual solution in other similar situations, when you want to include code for mutually incompatible architectures in the same object because you're going to test at run time which one to execute?

In D61824#1502690, @rprichard wrote:

I think that basically works. It would add a TLS segment to every Android executable, even those that aren't using ELF TLS:

• If the placeholder symbol has size 1 and 64-byte alignment, then every Android executable (targeting Q(29) and up) would have a PT_TLS segment of 64-byte size and alignment with gold or lld.
• If the placeholder symbol in .tdata has size 0 instead, then ld.bfd omits the .tdata section from the output if there aren't any other non-empty .tdata sections. This is a problem if there are other TLS sections (.tbss). Android is switching to lld, though, so maybe it's OK. (The NDK still defaults to bfd and gold.)
• If the placeholder symbol has a size of 48 bytes and 1-byte alignment, then libc.so can't use alignment to detect whether space was reserved. I can think of a couple ways for space to not be reserved:
  • Using an NDK that's too old
  • Using a too-old NDK API level, assuming this placeholder symbol is omitted when targeting old versions of Bionic (because Q(29) is currently rejecting an underaligned TLS segment...)

i think this should be fixed in the tools/runtimes that assume fixed tls offset abi that conflict with the elf tls abi.

i think glibc is right (comes up with a tlsoffset%p_align == p_vaddr%p_align for the module) and musl and other implementations are wrong (they may not get the tlsoffset right in this case: it seems musl always computes tlsoffset%p_align==0 on tls variant 1 targets).

In D40673#973638, @efriedma wrote:

as this patch is committed clang is broken (cannot use glibc headers)

This patch was supposed to *fix* compatibility with the glibc headers. If it doesn't, we should clearly revert it... but we need to figure out what we need to do to be compatible first.

From what I can see on this thread, we *must* define _Float128 on x86-64 Linux, and we *must not* define _Float128 for any other glibc target. Is that correct? Or does it depend on the glibc version?

also note that there is less than 3 weeks until glibc-2.27 is released, if the headers need a fix for clang then say so quickly

if clang wants to provide _Float128 then the f128 constant suffix (specified by TS18661-3) and builtin_inff128, builtin_nanf128, builtin_nansf128, builtin_huge_valf128 (gcc builtins required by math.h) need to be supported too.