re: Berkeley db 4.8 and newer, and sparc

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Fri, 29 Oct 2010, matthew green wrote:

> > gcc uses __arch64__ to indicate a 64-bit binary and __sparc_v9__ to 
> > indicate the v9 instruction set is in use.  With standard usage they aree 
> > equivalent.  However, if you give gcc fancy flags you can generate 32-bit 
> > v9 binaries.  But that's never done in practice.
> 
> i don't agree.
> 
> unlike my prior mail, i've actually checked, and we ship not only
> the 32 bit V9 GENERIC_SUN4U kernel with sparc64, but the 32 bit
> libraries shipped with sparc64 are also built the same way.  32 bit
> binaries that demand a v9 cpu:
> 
> /var/obj/sparc64/usr/src/compat/sparc64/sparc/usr/src/lib/libc/libc.so.12.173:
>  ELF 32-bit MSB shared object, SPARC32PLUS, V8+ Required, version 1 (SYSV), 
> dynamically linked, for NetBSD 5.99.38, not stripped

The libs don't really matter in this case since the MM bits in the pstate 
register are set based on the ELF header of the binary being exec-ed:

sparc64/machdep.c:

        /*
         * Set the registers to 0 except for:
         *      %o6: stack pointer, built in exec())
         *      %tstate: (retain icc and xcc and cwp bits)
         *      %g1: address of p->p_psstr (used by crt0)
         *      %tpc,%tnpc: entry point of program
         */
#ifdef __arch64__
        /* Check what memory model is requested */
        switch ((eh->e_flags & EF_SPARCV9_MM)) {
        default:
                printf("Unknown memory model %d\n", 
                       (eh->e_flags & EF_SPARCV9_MM));
                /* FALLTHROUGH */
        case EF_SPARCV9_TSO:
                pstate = PSTATE_MM_TSO|PSTATE_IE;
                break;
        case EF_SPARCV9_PSO:
                pstate = PSTATE_MM_PSO|PSTATE_IE;
                break;
        case EF_SPARCV9_RMO:
                pstate = PSTATE_MM_RMO|PSTATE_IE;
                break;
        }

and 32-bit binaries aare always TSO:

 
/*
 * 32-bit code requires TSO or at best PSO since that's what's supported 
on
 * SPARC V8 and earlier machines.
 *
 * 64-bit code sets the memory model in the ELF header.
 *
 * We're running kernel code in TSO for the moment so we don't need to 
worry
 * about possible memory barrier bugs.
 */

#ifdef __arch64__
#define PSTATE_PROM     (PSTATE_MM_TSO|PSTATE_PRIV)
#define PSTATE_NUCLEUS  (PSTATE_MM_TSO|PSTATE_PRIV|PSTATE_AG)
#define PSTATE_KERN     (PSTATE_MM_TSO|PSTATE_PRIV)
#define PSTATE_INTR     (PSTATE_KERN|PSTATE_IE)
#define PSTATE_USER32   (PSTATE_MM_TSO|PSTATE_AM|PSTATE_IE)
#define PSTATE_USER     (PSTATE_MM_RMO|PSTATE_IE)
#else
#define PSTATE_PROM     (PSTATE_MM_TSO|PSTATE_PRIV)
#define PSTATE_NUCLEUS  (PSTATE_MM_TSO|PSTATE_AM|PSTATE_PRIV|PSTATE_AG)
#define PSTATE_KERN     (PSTATE_MM_TSO|PSTATE_AM|PSTATE_PRIV)
#define PSTATE_INTR     (PSTATE_KERN|PSTATE_IE)
#define PSTATE_USER32   (PSTATE_MM_TSO|PSTATE_AM|PSTATE_IE)
#define PSTATE_USER     (PSTATE_MM_TSO|PSTATE_AM|PSTATE_IE)
#endif

So you can be pretty sure that 32-bit code is running in TSO and does not 
need any memory barriers.

Now it might be interesting to try running the kernel in one of the other 
memory models, but I think gcc probably only generates code for TSO.

> p.s.: my 32 bit install ultra10 builds with "-mcpu=ultrasparc".
> it's totally done in practice.

Interesting, but I don't think there are any bits in the 32-bit ELF header 
to tell the kernel to switch to something other than TSO.  I'm always 
surprised how often I stumble across optimizations that are only avaliable 
to 64-bit code.  What we really want is a switch for the compiler that 
tells it to generate 64-bit code that uses 32-bit pointers, and 
"-mcpu=ultrasparc" doesn't quite do that.

Eduardo