[Gllug] ELF, LSB [...] , stripped

[Nix]

On Mon, 21 Oct 2002, Tethys said:
> 
> Nix writes:
> 
>>Quite so. Example, from an UltraSPARC:
>>
>>/bin/ls: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1
>>(SYSV), for GNU/Linux 2.2.19, dynamically linked (uses shared libs), stripped
> 
> Is this just you being arbitrarily different again? For me:

No ;)

> isengard:~/tmp/zz% file *
> sparc32: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), dynamically linked (uses shared libs), stripped

compiled with no -mcpu / -xcpu (-xarch? can't remember) flags, hence v7
code.

> sparc64: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

likely compiled with no flags, again, but with a compiler targetting
sparc64.

> Admittedly, these are Solaris binaries, and my only Sparc Linux box is
> sparc32 only. But WTF are SPARC32PLUS and V8+? I thought SPARC went from
> V8 (32-bit) to V9 (UltraSPARC, 64-bit). There was a V8E with extensions
> suitable for embedded use, but V8+?

It's much more hideous than that. They're code-generation conventions
that map only approximately to architectures. Stealing factoids from the
Solaris 8 C compiler's manpage, which invented these terms:

v7: V8 without quad-precision floating point, integer multiply/divide,
    fsmuld (the lack of the integer multiply/divide makes it *dog* slow).
    For ancient crufty boxes that nobody's made sice Noah got out of the
    Ark.

v8a: V8 without quad-precision floating point or fsmuld. For e.g.
     MicroSPARCs.

v8: obvious. ;)

v8+: 32-bit V9 without quad-precision floating point or the VIS
     instructions (Sun's answer to MMX/Weitek :) ).

v8a+: 32-bit V9 without VIS. Since GCC can't generate code that uses
      VIS yet at all (no great loss; it's of limited use in most
      general-purpose code, like MMX, although it's not as badly
      designed as MMX was), all 32-bit code generated by GCC targeted
      for -mcpu=ultrasparc is by definition V8a+.

      This is also (excepting the lack of VIS) the fastest of all
      available options on UltraSPARC; 64-bit code is slower (for
      hopefully bloody obvious reasons, starting with `icache hit'
      and proceeding from there ;} )

v9: Full-blown 64-bit code. Hope you've got a very, very new
    binutils and glibc and a fairly new gcc, and appropriate
    cross-compilation tools.

There are some very weird V8 variants that can run v8plus code;
basically they're V8s with the 32-bit V9 instruction decoder.
I've never seen such a beast though.

-- 
`The tooth fairy teaches children that they can sell body parts for money.'
                       --- David Richerby

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug