>> >>> Has this been tested anywhere other than x86/x86_64 linux? >> Yes, I tested it on arm64 system. I applied 2 patches, previous 07/22 and >> this one 08/22. Everything >> was built successfully. Further to the building I did testing also. No new >> fails. > So how does that reconcile with H-P's note about the calls to > uw_install_context when FRAMES_VAR is defined as nothinng? > > + uw_install_context (&this_context, &cur_context, FRAMES_VAR); > > Doesn't that create a syntax error when FRAMES_VAR is defined, but with > no content? >
From: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01832.html It is done on purpose. There are /* Install TARGET into CURRENT so that we can return to it. This is a macro because __builtin_eh_return must be invoked in the context of our caller. */ #define uw_install_context(CURRENT, TARGET, FRAMES) \ do \ { \ long offset = uw_install_context_1 ((CURRENT), (TARGET)); \ void *handler = uw_frob_return_addr ((CURRENT), (TARGET)); \ _Unwind_DebugHook ((TARGET)->cfa, handler); \ _Unwind_Frames_Extra (FRAMES); \ __builtin_eh_return (offset, handler); \ } \ while (0) For non-CET targets, we have #define FRAMES_VAR [hjl@gnu-6 tmp]$ cat bar.c #define FRAMES_VAR #define foo(x, FRAMES) _Unwind_Frames_Extra (FRAMES) foo (xxx, FRAMES_VAR); [hjl@gnu-6 tmp]$ gcc -E bar.c # 1 "bar.c" # 1 "<built-in>" # 1 "<command-line>" # 31 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "<command-line>" 2 # 1 "bar.c" _Unwind_Frames_Extra (); [hjl@gnu-6 tmp]$ -- H.J.
