LGTM, refactor looks correct. in case of _LIBUNWIND_ARM_EHABI the director of the iteration over the phdrs changed but that is fine.

I think error is fine because realistically linking modules with different BTI settings will result probably a binary that crash runtime anyway if BTI is on.
otherwise turning BTI on just of a subset of object is useless.

Sorry for the trouble for now the patch is reverted.
I you agre I will resubmit it with ; REQUIRES: x86_64-linux and then figure out the rest of the targets later.

rebasing to the new patch series.

Rebased top of D85649.

adding an option _LIBUNWIND_REMEMBER_HEAP to store the state on the heap.
I kept the default on the stack because it should be fine for most cases.

LGTM

@nickdesaulniers Thanks for the review, comments are addressed.

I'll update this after other PAC/BTI patches got merged.

ping

@chill Could you check the latest update? I think it should be submitted with D84502 together.

I support the idea, once I proposed back then ( see D75181 )

I need to update it due to changes in the dependent patches.

Sync with D85649.

Abandoning in favour of D85649.

updating tests too. check-llvm, check-clang passes.

Fix review comments.

Always emit xpac* instructions as discussed in D84502.

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.

And now uploading the new patch.

The produced code for the non return function might save an unsigned LR to the stack and that might be usable to craft a gadget IMHO. The probability is quite low but still.

LGTM

XPACI could be emit when it is available, only the if (MF.getFunction().hasFnAttribute("sign-return-address")) { need do be dropped from the patches IMHO.

FWIW GCC has a "sign-return-address" function attribute with a default value of "none". It is considered deprecated, however, in favour of "branch-protection"

This is just the internal representation, the function attribute in C/C++ source is the "branch-protection".

This version of the patch behaves as gcc for case when no function present and when function has -mbranch-protection attribute without compiler flag.
The logic should be in clang because in llvm we won't have enough information to handle these things. (see D75181)

Would it be better to add a new value to "sign-return-address" as "none"? I don't see any other alternative option, I'm open to any other idea.

fix review comment.

Added here as I see:
https://github.com/llvm/llvm-project/blob/19bc9ea480b60b607a3e303f20c7a3a2ea553369/libcxxabi/test/CMakeLists.txt#L57

Thanks.
Cmake file of libcxxabi seems fine to me, it just needs -DLIBCXXABI_USE_LLVM_UNWINDER=YES.

fix review comments.

LGTM

If any function has the attribute "sign-return-address", then the output note
section should have PAC bit set. The return address signing is completely local
to the function, and functions with or without return address signing can be
freely mixed with each other.

That is true PAC and non-PAC functions can be mixed.
Does one function makes the "all executable sections" pac-ret enabled?
BTW GNU_PROPERTY_AARCH64_FEATURE_1_PAC is not really used for anything.

Patch for gcc is merged. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a70d5d81c41048556fd86eaa1036018a6bfba115

This is a WIP patch, just shows my current thinking.

Ping.

@j0le patch is landed but I just realised the review is still blocked by @compnerd. So it won't be closed I think, that is my bad.

In D80791#2120755, @kees wrote:

In D80791#2120503, @nickdesaulniers wrote:

Might someone wish to disable PAC/BTI on an individual function, while having it on for the rest? I guess that would mean you can't call that function indirectly?

It would mean you can't call it _at all_, not just indirectly. :) Which is why I still think the warning is useful. Perhaps don't warn for the functions with the attribute?

Function level attributes could set different attributes for functions. If function attribute is used then I assume the user know what he/she is doing so no need to emit a warning.
Maybe some would ensure the function is only directly called and never called indirectly by enforcing the branch-proctection=None or Pac-ret.
By default this warning shall not present anyway, especially for LLVM internals.

This patch solve this too: https://bugs.llvm.org/show_bug.cgi?id=46480

Simplify the patch, rebased.

@j0le, I will commit later this week for you.
@compnerd do you have any comment for this version?

Rename the flag to -mmark-bti-property

I'm going to refactor this and rebase on my other changes.

I got some comment internally, the -mbti might suggest it enables the bti feature so I'm going to rename the flag to -mmark-bti-property.

Sorry for the delay, it is okay to say "ping" after a while :)
LGTM

Patch rebased, now should apply clearly.