> was there a special reason why ucontext has lower priority than asm
> implementations?

Sure, ucontext is much slower. The whole point of the asm implementations
is to get good performance on common platforms, with ucontext as a fallback.

Why not fix the missing .cfi_startproc? I wonder what is special on the
SmartOS platform for this to show up only there?

Try generating the assembler output from my_context.c (gcc -S) and check
where the .cfi_escape instruction ends up and why there is no .cfi_startproc
on that function.

Does my_context_spawn() need _attribute_((noinline))?
Or is dwarf debug info maybe disabled on that platform?

If the .cfi_escape is not available on SmartOS, it can just be disabled in
the code, there is already an #ifdef for other situations. The .cfi_escape
is just a hint to debuggers that the stack trace ends here, it can be safely
omitted from the code.

(But it would still be interesting to see the assembler output from the
compiler to understand what is going on).

OpenIndiana Hipster edition is also affected:

openxs@hipster:~/git/server$ uname -a
SunOS hipster 5.11 illumos-f8554bb i86pc i386 i86pc Solaris

The fix described by Ben above helped to proceed.

I've just run into the same issue when compiling MariaDB 10.2.12 on Solaris 11.4
Beta with the bundled gcc 5.5 (64-bit-default configuration).

The issue is in no way SmartOS-specific, but can happen on any x86 target: gcc
checks at build time if the toolchain used (assembler and linker) do support the
.cfi_* directives. If it doesn't (support is incomplete or buggy or there are other issues
as on Solaris with the bundled linker), it disables support for them and instead
open-codes unwind info.

In such a case (when the assembler is partially able to handle cfi directives), it
will complain about missing .cfi_startproc.

There are several ways out of this:

• If (as it turned out in my case) gcc's configure check for cfi directive use is buggy,
  one can just override it with -fdwarf2-cfi-asm.

• To avoid compilation failures with the unconditional use of cfi directives (.cfi_escape here), one can check for __GCC_HAVE_DWARF2_CFI_ASM which gcc predefines.

• And finally one could open-code the .eh_frame section, as is done e.g. in libffi.

For the moment, the middle option should be use to avoid using cfi directives
if the toolchain cannot support them!

cvicentiu I have a patch for this, so grabbing this if that's ok.

Merged to 3.3