[libcxx-commits] [PATCH] D105968: [libunwind][CET] Support exception handling stack unwind in CET environment

[xiongji90 via Phabricator via libcxx-commits]

xiongji90 added a reviewer: compnerd.
xiongji90 added inline comments.


================
Comment at: libunwind/src/UnwindLevel1.c:47
+#if !defined(_LIBUNWIND_CET_ENABLED)
+#define __unw_phase2_resume(cursor, fn) __unw_resume((cursor))
+#elif _LIBUNWIND_CET_ENABLED == 1
----------------
xiongji90 wrote:
> compnerd wrote:
> > xiongji90 wrote:
> > > compnerd wrote:
> > > > Why does this have to be a macro?  Can we just define the function instead?
> > > Hi, @compnerd 
> > > In previous version, I defined a function the code looks like following:
> > > void __unw_phase2_resume(cursor, fn) {
> > > __LIBUNWIND_POP_CET_SSP(...);
> > > ....
> > > ....
> > > __asm__ volatile(....)
> > > }
> > > The stack layout looks like following if compiler doesn't do any optimization to __unw_phase2_resume:
> > > _____________________
> > > .....user functions
> > > ______________________
> > > __cxx_throw
> > > _______________________
> > > _Unwind_RaiseException
> > > _______________________
> > > unwind_phase2
> > > _______________________
> > > __unw_phase2_resume
> > > ________________________
> > > 
> > > Under such circumstances, the stack frame for __unw_phase2_resume will be skipped too and we must adjust CET shadow stack for it.
> > > However, as we can see, the __unw_phase2_resume will never return. I am afraid compiler may directly jump to this function instead of "call" it. If so, there will be no stack frame for __unw_phase2_resume and if compiler uses "jmp" to jump to it instead of calling it, we mustn't adjust CET shadow stack for it.
> > > In our source code, we can't know whether compiler will do such optimization and we can't decide whether we should adjust CET shadow stack for __unw_phase2_resume. So I used macro here to avoid this problem.
> > > I used inline asm to jump to __libunwind_Registers_x86_64_jumpto for the same purpose.
> > > Thanks very much.
> > I wonder if we can get away with some combination of `noinline`, and pragmas for `no-optimize-sibling-calls`.
> Hi, @compnerd 
> I think using combination of following:
> 1. using __attribute__((noinline)) to decorate target functions
> 2. building source file containing target functions with -fno-optimize-sibling-calls
> can help us to get away with the issue mentioned above. I only found gcc/clang compiling options for "-fno-optimize-sibling-calls" and didn't find corresponding pragma or attribute, so if we choose to use "-fno-optimize-sibling-calls", tail call optimization for other functions will be disabled too which seems to be overshooting.
> And if choosing the combination of "noinline" and "-fno-optimize-sibling-calls", we are relying on gcc/clang's implementation which is a implicit dependency, using macro here should be safe to all compilers.
> 
> Thanks very much.
Hi, @compnerd 
If you have concern about the macro "unw_phase_resume", I can try to update the patch to use combination of "noinline" and "-fno-optimize-sibling-calls". And do we have any way to use "no-optimize-sibling-calls" to decorate a function? I only found compiling option "-fno-optimize-sibling-calls".
Thanks very much. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105968/new/

https://reviews.llvm.org/D105968