rebased, fixed my own comments.

In D93428#2461343, @apazos wrote:

Thanks Daniel for the explanation.

No problem at all.

Is there a reason why assembly files have a different flag (i.e. -mmark-bti-property) to create the .note.gnu.property with the BTI entry?

The .note.gnu.property is already generated when C/C++ files are compiled with -mbranch-protection=bti.
-mmark-bti-property is only for assembly file where the .note.gnu.property should be added manually otherwise.

@manojgupta Thanks for the feedback, let me know if you have updates.

unwind_leaffunction.pass.cpp could be enable too for aarch64.

LGTM

LGTM, Thanks.

Done see: D91182

LGTM, Thanks!

https://bugs.llvm.org/show_bug.cgi?id=47142 this effects this. the missing unwind info make forceunwind fragile.

self.cxx has a function to test compiler flags addFlagIfSupported but there is no support for linker flag (yet).

rebase, add MINGW32

ping

Add a simple test and fixes.
This version passes on arm32 - armv7l-unknown-linux-gnueabihf -

_Unwind_Stop_Fn shall not have different signature for EHABI.

Those are gone from the view, so ignore what I said.

LGTM, just please fix the lint issues in the llvm/lib/Target/AArch64/AArch64MachineFunctionInfo.h

LGTM

The system-* and native are used in clang and lldb only, so dropped.
I only added them for consistency across llvm components.

some test never runs due to these features are missing. I realised this when tried to run this one: https://github.com/llvm/llvm-project/blob/master/libunwind/test/remember_state_leak.pass.sh.s#L1

update module flag handling due to the change is merged in: D85649.

Thanks for the review. It looks like I still need someone from the libunwind group to accept it.

@nickdesaulniers

one kernel image that runs on hardware both with and without BTI ISA extensions?

In case of BTI one image could run on both HW due to BTI is in the no-op space.

@chill ping.

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 )