svn commit: r335873 - in head: . sys/amd64/amd64 sys/amd64/include sys/conf sys/i386/i386 sys/i386/include sys/sys sys/vm

[Mark Millard]

> Author: mmacy
> Date: Mon Jul  2 19:48:38 2018
> New Revision: 335873
> URL: 
> https://svnweb.freebsd.org/changeset/base/335873
> 
> 
> Log:
>   inline atomics and allow tied modules to inline locks
>   
>   - inline atomics in modules on i386 and amd64 (they were always
>     inline on other arches)
>   - allow modules to opt in to inlining locks by specifying
>     MODULE_TIED=1 in the makefile

I recently found the following about ABI incompatibilities
between clang and gcc relative to C11 language based
atomics:

https://bugs.llvm.org/show_bug.cgi?id=26462

26462 – GCC/clang C11 _Atomic incompatibility


So are there implications about building the kernel
vs. modules that overall mix the toolchains once
modules are loaded? Do the toolchains need to match,
at least for amd64 and i386 TARGET_ARCH 's?



For reference as an introduction to the material
in llvm's 26462 . . .

It appears that the normal source of platform ABI definitions are
not explicit/detailed in the area and allow for incompatibilities
in this area. clang and gcc made differing choices absent being
constrained to match.

An example (a powerpc64 context was indicated):

struct A16 { char val[16]; }; 
_Atomic struct A16 a16; 
// GCC:
_Static_assert(_Alignof(a16) == 16, ""); 
// Clang:
_Static_assert(_Alignof(a16) == 1, ""); 


Non-power-of-2 is a general problem
(not a powerpc64 context from what I can
tell):

struct A3 { char val[3]; };
_Atomic struct A3 a3;
// GCC:
_Static_assert(sizeof(a3) == 3, "");
_Static_assert(_Alignof(a3) == 1, "");
// Clang:
_Static_assert(sizeof(a3) == 4, "");
_Static_assert(_Alignof(a3) == 4, "");


Comment 6 (by John McCall) is relevant:

QUOTE
Anyway, while I prefer the Clang rule, the GCC rule is defensible, as are any number of other rules.  The important point, however, is that having this discussion is not the right approach to solving this problem.  The layout of _Atomic(T) is ABI.  ABI rules are not generally determined by compiler implementors making things up as they go along, or at least they shouldn't be.  The Darwin ABI for _Atomic is the rule implemented in Clang, which we actually did think about carefully when we adopted it.  Other platforms need to make their own call, and it probably shouldn't just be "whatever's implemented in GCC", especially on other platforms where GCC is not the system compiler.
END QUOTE


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)