svn commit: r295561 - in head: include sys/mips/include sys/powerpc/include sys/sparc64/include sys/sys sys/x86/include

[Konstantin Belousov]

On Sun, Feb 14, 2016 at 05:47:19AM +1100, Bruce Evans wrote:
> How likely is third party code to use undocumented internals of opqaue
> types when FreeBSD code mostly doesn't used them.
I already said that they are used.  Base system cannot be a benchmark
there because base code does not implement modern runtime (i.e. automatically
managed memory and type-safe or generally safe execution environment).

As a random example, from sbcl (common lisp implementation) runtime:

#if defined(LISP_FEATURE_FREEBSD)
#if defined(LISP_FEATURE_RESTORE_TLS_SEGMENT_REGISTER_FROM_CONTEXT)
void
os_restore_tls_segment_register(os_context_t *context)
{
    load_fs(context->uc_mcontext.mc_fs);
}
#endif
...


> 
> I checked all files in /usr/src outside of /sys/ that contain "ucontext.h".
> There are 71 such files with 204 lines matching "mc_".  The actual users
> of mcontext_t's internals are:
> 
> contrib/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc: 8 instances
> contrib/compiler-rt/lib/sanitizer_common/sanitizer_freebsd.h: 30 instances
> lib/libc: 102 instances
> lib/libthread_db: 60 instances
> tools/KSE/ksetest/kse_threads_test.c: 2 instances
> tools/KSE/rr/rr.c: 2 instances
> 
> So there are 4 instances outside of libraries (counting compiler_rt as
> a libraries) and these 4 are to support KSE which went away about 11
> years ago IIRC.  tools/KSE doesn't compile now of course.  The first
> error is that its asm source file is i386-only, so fails on i386.
> The next error is that its primary (?) API file <sys/kse.h> no longer
> exists.
> 
> I hoped to find no instances outside of libc.  Bits in contrib are are
> problem.
The contrib is not a problem, it demostrates another legitimate use of
the signal handlers.  Any code which uses exceptions for more than error
reporting does understand ucontext and mcontext.