GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?

[Darryl L. Miles]

Is there a document or standard (or group of standards) that define the 
collective ABIs of GNU/Linux systems using ELF binary formats of various 
CPU architectures, including at least:
  IA32 (i386/i686/AMD64/EMT64/etc...)
  ARM (v5, v5t, v7, etc...)

What is the policy of the GNU toolchain, does it attempt to support a 
super-set of features where code was contributed but not directly 
set/enforce policy itself.  This being a matter for a distribution 
creator to establish.



My concern comes from what looks to be non-backwards compatible changes 
being made by the MeeGo distribution of Linux.  Specifically the 
enablement of SSSE3 IA32 instructions for "general purpose code 
generation", one possible motive for this is that a particular hardware 
vendor can claim in marketing the platform is optimized for XYZ 
technology/product, the thing they are actively trying to sell of the 
day.  This doesn't necessarily make for a good engineering choice.

While I accept that any distribution can do what they want, given the 
choice and resources I might wish to rebuild the entire open source 
project based around a better set of rules over this matter, since I 
have an interest in using the software but being a developer want the 
least amount of headaches looking into the future.  I also wish to 
achieve the goals to be able to provide a fully native SSSE3 optimized 
complete system but want other systems to behave in a repeatable and 
consistent way when binaries ultimately end up shared across them 
(desktop Linux).



Does GCC support use of newer CPU instructions for "general purpose code 
generation" ?  If so what kind of situations might they get selected for 
use ?  It is possible the situation is being misinterpreted by me, if 
GCC can not actually schedule newer instructions in code generation.



So my next question is what support is there in the various formats, 
technologies and runtime libraries to provide a backwards compatible 
solution, such that a binary from one system when put on another can 
have any hardware incompatibilities detected at the soonest opportunity, 
for example upon execution, soon after execution, during DSO loading:

1) ELF magic or hwcap (this would allow the kernel to error during the 
exec() system call, knowing that the format is not supported by the 
system).  DSOs loaded would also error with the same checking.  Ideally 
a hwcap system ideally doesn't want to be a rigid bitmask but some kind 
of extensible ASN.1 system where anyone can register for their own 
hierarchical domain and assign whatever they want from within it.

2) Use of a bespoke/custom Dynamic Linker path, I would guess any system 
doing this would be free to implement an alternative ABI.  Mixing 
binaries between systems would result in them not working due to lack of 
Dynamic Linker at that path.

3) Do the ABIs directly discuss of explain how such matters should be 
addressed, i.e. by guarding the execution of new CPU instructions by 
runtime checking.  This might mean whole optimized DSOs are loaded 
instead, or it might mean bunch of symbols would be redirected to 
optimized code within the same DSO, or it might mean an inline change of 
the flow of execution.  While I understand ABIs maybe 
open/loose/ambigious to allow new technologies and ideas to exist when 
known interoperability problems appear then guidelines should exist that 
provide technical answers to guide implementers so that good citizenship 
may follow.

4) Use of some ELF section to describe additional runtime checking rules.



The problem stems from hit and miss users getting SIGILL due to use of 
unguarded IA32 instructions being executed on non compatible (older) 
CPUs.  The kernel doesn't provide any trap and emulation, so the general 
purpose applications abort resulting is possible data loss.  Do 
guidelines exist within the GNU/Linux ABI on how to be a "good citizen" 
and help systems differentiate incompatible binaries so they simply 
don't run instead of causing a SIGILL potentially some months after 
execution started, because over the entire executable only a tiny 
handful of these instructions got selected by the compiler for use and 
that code didn't get run for a long time after the executable started.



The next matter is has anyone done any studies on the performance 
difference when enablement of newer instructions is possible for 
"general purpose code generation".  I'm not so interested in specialized 
use cases such as codecs, compression, encryption, graphics, etc... I 
consider these specialized use cases for which many applications and 
libraries already have a workable solution by "guarding" the execution 
of instructions that optimize such algorithms by checking the CPU 
runtime support.  I'm interested in the facts on how much benefit 
regular code gets from this choice.

Thanks,

Darryl