ojhunt wrote:

> @ojhunt I closed all the threads which are no longer relevant or are 
> duplicates. 

👍

> ## To be done in scope of this PR
> ### Trivial formatting issues
> These require almost zero effort to apply. Please consider fixing these first 
> so we do not need to worry about them anymore.

Done

> 
> ### Non-trivial styling-related issues
> 1. Refactor preprocessor checks against ptrauth. See thread 
> https://github.com/llvm/llvm-project/pull/143230/files#r2369029642 and commit 
> [644405b](https://github.com/llvm/llvm-project/commit/644405b56cfa59dd3787119182df087dff6e756c)
> 2. Avoid use of `__ptrauth_restricted_intptr` which is not present in 
> mainline. See thread 
> https://github.com/llvm/llvm-project/pull/143230/files#r2369036612 and commit 
> [a2390e1](https://github.com/llvm/llvm-project/commit/a2390e1e285023af78d27d768540bb8f30efea76).
>  I do get the point that it's needed in downstream, but I suppose that it's 
> better to avoid exposing downstream-specific stuff to mainline. I suppose 
> that you can use a simple downstream patch over mainline libunwind which 
> would resolve the build issue for you.

That would mean that apple clang will not be able to build the runtimes. That's 
not a real option.

> 3. Do smth with `[[maybe_unused]]` attribute which only serves as a 
> workaround for a spurious compiler bug. See thread 
> https://github.com/llvm/llvm-project/pull/143230/files#r2368805350 and commit 
> [4eaa8c7](https://github.com/llvm/llvm-project/commit/4eaa8c7dff48bfc96b071ab0e219369839e3758c)

I've moved this behind a matching #define of the code that calls them, I'm 
trying to work out if there is a real reason for the functions being separated 
from their usage as much as they are.

> ### An issue causing a runtime crash
> Do not mix pac-ret and ptrauth_returns. See thread 
> https://github.com/llvm/llvm-project/pull/143230/files#r2369419226 and commit 
> [ced8b99](https://github.com/llvm/llvm-project/commit/ced8b99373c9b0756f1718999996f44a74bdf46d).

Fixed with an arm64e guard.

> ### Other non-trivial issues
> Verify FP is handled correctly 
> https://github.com/llvm/llvm-project/pull/143230/files#r2369428305

It is, I've fixed the misleading - we were experimenting with signed frame 
pointers for a while.

> ## To be done as a follow-up
> 1. [[PAC] Update pointer authentication docs #96528 
> (comment)](https://github.com/llvm/llvm-project/issues/96528#issuecomment-3320192622)
> 2. [[PAC][libunwind] Refactor way of describing internal signing schemas 
> #160101](https://github.com/llvm/llvm-project/issues/160101)
> 3. [[PAC][libunwind] Unify signed return address handling logic 
> #160110](https://github.com/llvm/llvm-project/issues/160110)
> 4. [[PAC][libunwind] Investigate if compatibility with v8.2-a could be 
> enhanced #160114](https://github.com/llvm/llvm-project/issues/160114)

Pinged Ahmed on this one, I don't know the full impact of that change

> 5. [[PAC][libunwind] Enhance comments and error messages related to libunwind 
> hardening #160117](https://github.com/llvm/llvm-project/issues/160117)

My preference would be to remove those from release builds entirely and replace 
LIBUNWIND_ABORT() with explicit immediate traps.

> 6. [[PAC][libunwind] Move signing schemas which are part of public ABI to 
> ptrauth.h header #160119](https://github.com/llvm/llvm-project/issues/160119)

This is possibly difficult. The functional ABI implication of most of these is 
purely between libcxx and libcxxabi, and our platform model does not support 
updating/changing those separately, which means we think we might be able to 
change/improve some of the aspects in future. Moving them to `ptrauth.h` 
functionally removes that option even if there was no technical reason to.

> 7. [[PAC][ibunwind] Support signed personality pointer on Linux targets 
> #160120](https://github.com/llvm/llvm-project/issues/160120)

this is the "personality" discriminated one right? I think I already 
incorporated it into the latest revision.

https://github.com/llvm/llvm-project/pull/143230
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to