as a base I borrow some code from glibc, and remove related files
(mostly _ucontext.h/ucontext.h) from genode

May I ask what is the reason for choosing and incorporating the glibc
implementation rather than using/enabling the one in the FreeBSD libc?

1. current implementation of context switch in FreeBSD done completely in kernel via sys call. E.g. this is full code of getcontext function (stored in genode, not used):

#include <machine/asm.h>

__FBSDID("$FreeBSD: releng/12.0/lib/libc/i386/sys/getcontext.S 258451 2013-11-21 22:31:18Z andreast $");

#include <SYS.h>

* This has to be magic to handle the multiple returns.

* Otherwise, the setcontext() syscall will return here and we'll

* pop off the return address and go to the *setcontext* call.

WEAK_REFERENCE(__sys_getcontext, _getcontext)

WEAK_REFERENCE(__sys_getcontext, getcontext)

ENTRY(__sys_getcontext)

movl (%esp),%ecx /* save getcontext return address */

mov $SYS_getcontext,%eax

KERNCALL

jb HIDENAME(cerror)

addl $4,%esp /* remove stale (setcontext) return address */

jmp *%ecx /* restore return address */

END(__sys_getcontext)

.section .note.GNU-stack,"",%progbits

2. context family support do require complex and misleading structure, e.g. take a look for setcontext code:

#include <sys/cdefs.h>

__FBSDID("$FreeBSD: releng/12.0/lib/libc/sys/setcontext.c 326576 2017-12-05 20:19:13Z emaste $");

#include <sys/types.h>

#include <ucontext.h>

#include "libc_private.h"

__weak_reference(__sys_setcontext, __setcontext);

__sym_compat(setcontext, __impl_setcontext, FBSD_1.0);

__weak_reference(setcontext, __impl_setcontext);

__sym_default(setcontext, setcontext, FBSD_1.2);

int

setcontext(const ucontext_t *uc)

{

return (((int (*)(const ucontext_t *))

__libc_interposing[INTERPOS_setcontext])(uc));

}

I try to understand how all these __libc_interposing works - and fail, this is not currently supported in genode as I understand

3. ucontext.h and related is isolated in current libc and could be easily replaced (because it used only in *context family of functions and signals which has only rudimentary support

4. glibc implementation is straightforward and well supported, relatively small and suitable for big set of platforms, without complex kernel/__libc_interposing analogous and could be borrowed (copied) with minimal efforts, I can confirm this.

5. glibc implementation of these functions do contain potentially useful security feature of shadow stack support (under SHSTK_ENABLED define - not enabled in my patch)

So, I consider option to use existing freeBSD version and replacement of code of functions to ones from glibc - and think that this make everything too complex, related infrastructure not clear and not easy to support. May be I am wrong.

for me simplest for implementation and, especially, for future support - is chosen approach (with part of glibc port). It is simple and straightforward, easy to extend to arm/etc.

Another option I consider is a usage of native context-switch functions for genode low level Os (OS - dependent). Anyway, it will significantly lower performance, and not portable option, so, I do not choose it.

Strictly speaking containg such a large patch makes the commit
unsuitable for the Genode main repo as the burden of maintaing it
falls on our shoulders at the end and the reason for including it in the
first place is not immediately clear.

significant part of patch is a removal of old files like ucontext.h and plain addition of new files, take a look for statistics, no complex updates of files involved:

fgrep \@\@ ./repos/libports/src/lib/libc/patches/zmcontext.patch

@@ -0,0 +1,1 @@

@@ -0,0 +1,7 @@

@@ -0,0 +1,1092 @@

@@ -0,0 +1,3 @@

@@ -0,0 +1,279 @@

@@ -0,0 +1,590 @@

@@ -0,0 +1,3 @@

@@ -0,0 +1,18 @@

@@ -0,0 +1,124 @@

@@ -0,0 +1,137 @@

@@ -1,109 +1,155 @@

@@ -0,0 +1,201 @@

@@ -0,0 +1,256 @@

@@ -0,0 +1,28 @@

@@ -1,48 +0,0 @@

@@ -0,0 +1,97 @@

@@ -0,0 +1,113 @@

@@ -0,0 +1,129 @@

@@ -1,167 +0,0 @@

@@ -1,54 +0,0 @@

By the way, I can make patch smaller if you give me a direction how to remove some files during install or patch process without patch itself, may be via .mk file (e.g. libc-gen.mk)

For better or worse, we still lack the resources (read man-power) as well
as a deeper understanding for the issues at hand when it comes to the
requirements of the golang-runtime (which somewhat is a consequence of
the lack of resources) that such an undertaking arguably deserves.