Can a script find out, under SVR4, the ABI to which a machine conforms?
Guy Harris
will, if given the "command" SI_ARCHITECTURE, return "a string
describing the instruction set architecture of the current system, e.g.,
'mc68030', 'm32100', or 'i80486'."
It also hints that said "command" is used by "uname -p" to return the
"processor type" string.
Unfortunately, as I read it, that *doesn't* correspond to the ABI to
which the machine conforms:
there isn't a Motorola 68030 ABI - there's a Motorola 68K ABI,
but machines with 68020's, 68030's, or 68040's all have the
right instruction set for the 68K ABI;
similarly, there isn't an Intel 486 ABI- there's an Intel i386
ABI, but machines with 386's, 486's, or presumably
586's^H^H^H^H^HPentia have the right instruction set for the
i386 ABI, or simulate the missing instructions in software, e.g.
if the floating-point unit is missing;
the same presumably applies to other ABIs for processors for
architectures that have acquired new instruction over time.
A *program* probably doesn't have to care what the ABI is for the
machine on which it's running - if it's the wrong ABI, it won't run,
period - but a *script* might care. In particular, Frame Maker has a
"fmarch" script that, at least on some platforms, is used to select the
directory from which executables are to be run.
If, in fact, "uname -p" returns a *detailed* processor type, rather than
an ABI type, "fmarch" and, conceivably, other scripts will have to know
all the detailed processor types that support a particular ABI, and may
thus have to change over time as new instructions are added to
instruction sets and new processor types are added.
Perhaps later SVR4.x releases have already done this, but if not:
There should be a new SI_ABI "command" for "sysinfo()", that
returns a string that indicates the ABI to which a system
conforms; for example, it would return "i386", or something such
as that, on 80386-based machines, 80486-based machines,
Am386-based machines, Cyrix-chip-based machines, Pentium-based
machines, etc..
The string returned by SI_ABI for a particular ABI should be
part of the ABI specification.
There should be a "-b" flag to "uname" to write the string
returned by SI_ABI to the standard output.
Mats Wichmann
>The SVR4 documentation I have indicates that the "sysinfo()" routine
>will, if given the "command" SI_ARCHITECTURE, return "a string
>describing the instruction set architecture of the current system, e.g.,
>'mc68030', 'm32100', or 'i80486'."
>It also hints that said "command" is used by "uname -p" to return the
>"processor type" string.
>Unfortunately, as I read it, that *doesn't* correspond to the ABI to
>which the machine conforms:
Uname -p is inended as the generic processor type, but was not firmly
enough specified to guarantee that. The MIPS ABI Group Technical
Committee wrestled with this problem for a while, decided that there
simply hadn't been enough standardization on sysinfo (esp. amongst the
members of that group!) and defined a series of extensions to sysinfo
to handle the needs of that ABI. Comments were submitted (I believe)
to the ABICC (UI's ABI Coordinating Committee), but I don't know the
results. I'll look into it, however.
> the same presumably applies to other ABIs for processors for
> architectures that have acquired new instruction over time.
>A *program* probably doesn't have to care what the ABI is for the
>machine on which it's running - if it's the wrong ABI, it won't run,
>period - but a *script* might care. In particular, Frame Maker has a
>"fmarch" script that, at least on some platforms, is used to select the
>directory from which executables are to be run.
Programs may care about other issues - what _version_ of the ABI,
for example, or the detailed processor type (for (yuck) licensing
reasons. There's an open can of worms here.
>If, in fact, "uname -p" returns a *detailed* processor type, rather than
>an ABI type, "fmarch" and, conceivably, other scripts will have to know
>all the detailed processor types that support a particular ABI, and may
>thus have to change over time as new instructions are added to
>instruction sets and new processor types are added.
>Perhaps later SVR4.x releases have already done this, but if not:
> There should be a new SI_ABI "command" for "sysinfo()", that
> returns a string that indicates the ABI to which a system
> conforms; for example, it would return "i386", or something such
> as that, on 80386-based machines, 80486-based machines,
> Am386-based machines, Cyrix-chip-based machines, Pentium-based
> machines, etc..
Not done, but not a bad idea...
--
Mats Wichmann
Unisoft Corporation
ma...@unisoft.com (or ma...@netcom.com)
Silly Disclaimer: speaking only for myself, except when I'm not.
Andy Roach
ABI conforming script may call. If a script is attempting to perform
different functions based on architecture type then by definition "sort of"
the script is non ABI conforming.
The goal of the ABI is one executable per architecture and in the case of
scripts, one script per generic ABI for all machines.
Now this doesn't address the real world problem of having servers
export a tree which contains binaries for a bunch of different machines,
but some view this as an admin problem not an ABI problem.
Andy
Guy Harris
Because the script might be a wrapper script around an application -
let's give the application the hypothetical name "Frame Maker" - that
finds out the architecture for the machine, and runs the appropriate
binary, because the hypothetical vendor of this application - let's give
them the hypothetical name "Frame Technology" - apparently wants to have
shared versions of the non-architecture-dependent files, and separate
directories for the architecture-dependent files.
And yes, I *did* get bitten by that when I tried firing Frame up on a
Solaris 2.x machine here; the obvious fix, of using "uname -p", isn't
guaranteed to allow the same binary to be used on, for example,
386-based and 486-based boxes.
If you don't think Frame is doing the right thing, try convincing *them*
of that - and, if you don't succeed, consider that having "uname -b"
might be better than forcing Frame to have to recognize that "i80386"
and "i80486" and "iPentium" and... are really equivalent for its
purposes.
And also consider that Frame might not be the *only* application that
does this....
>The Generic ABI lists all the commands an
>ABI conforming script may call. If a script is attempting to perform
>different functions based on architecture type then by definition "sort of"
>the script is non ABI conforming.
So? Who cares? What's the *cost* of putting in a "get the architecture
name" option into "uname"?
>Now this doesn't address the real world problem of having servers
>export a tree which contains binaries for a bunch of different machines,
>but some view this as an admin problem not an ABI problem.
And some don't.