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

[Bruce Evans]

On Fri, 12 Feb 2016, Ruslan Bukin wrote:

> On RISC-V it fails with __uint128_t:
>
> struct fpregs {
>        __uint128_t     fp_x[32];
>
> how to fix?

This seems to be an old bug.  __uint128_t shouldn't be used unless it
is supported by <stdint.h>.  In old versions of FreeBSD, I used
something like __attribute__(( ... __mode__(__XI__) ... )) for related
problems with long long.  Here __uint128_t is a compiler extension that
is not very different from the attribute.

This seems to be in arm64/ucontext.h, but the name there is spelled fp_q.

arm64/ucontext.h has mounds of namespace errors.  It uses the following
names in the application namespace:

     gpregs, gp_*
     fpregs, fp_*
     mc_* (like other arches)

Checking this for other arches:

arm:
Clean.  It uses an excessive number of leading underscores (2) instead
of none for things like gp_*.  It spells __uint32_t verbosely as
'unsigned int.

i386:
Just the bogus name __spare__.  The 2 trailing underscores don't even
serve a technical purpose.

mips:
Mounds of namespace errors:

     sr, mullo, mulhi (2 instances)
     __spare__ (3 instances)
     Likely pollution from nested include of freebsd32_signal.h (doesn't
       seem to be kernel-only)
     SZREG
     UCTX_REG
     UCR_*

powerpc, sparc64:
OK except for mc_* after adding underscores to uint*_t and register_t.
Both use some hackish #defines of struct member names.  powerpc
#define's mc_* so is more fragile; sparc64 #define's _mc_* instead,
but uses the usual mc_* for the struct member names.

x86:
Clean except for mc_*.

[Context lost to top posting]

Bruce