Date: Sat, 13 Feb 2016 21:12:59 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r295561 - in head: include sys/mips/include sys/powerpc/include sys/sparc64/include sys/sys sys/x86/include Message-ID: <20160213191259.GF91220@kib.kiev.ua> In-Reply-To: <20160214050522.J1687@besplex.bde.org> References: <201602120738.u1C7cKpq093956@repo.freebsd.org> <20160212232717.P894@besplex.bde.org> <20160212143630.GS91220@kib.kiev.ua> <20160213021939.S1340@besplex.bde.org> <20160212173641.GV91220@kib.kiev.ua> <20160213070506.N2501@besplex.bde.org> <20160213101623.GZ91220@kib.kiev.ua> <20160214035852.D918@besplex.bde.org> <20160213172321.GE91220@kib.kiev.ua> <20160214050522.J1687@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160213191259.GF91220>