Re: [ft-devel] No support for side-by-side installation of x86-64 and i386

[Henrik Grubbström]

On Thu, 8 Dec 2005, address@hidden wrote:

> Hi,
>
> On Wed, 7 Dec 2005 14:15:52 +0100 (CET)
> > On Wed, 7 Dec 2005, address@hidden wrote:
> > > I see. Let me clarify the condition: the issue you reported is
> > > specific to GNU/Linux on x86-64, ppc64 and s390x.
> >
> > Solaris 64-bit also has ABI-separated library directories:
>
> Great Thank you for helpful info.
> Let me ask more about the separations on Solaris:
>
> * Optional softwares use same separation rules?
>  For example, there are something like /usr/X11R6/lib/64 ?

Yes. From my Solaris x86 machine:

  $ ls -ldF /usr/X11/lib/*64
  lrwxrwxrwx   1 root     root           5 May  4  2005 /usr/X11/lib/64 -> 
amd64/
  drwxr-xr-x   2 root     bin          512 Jul 24 04:03 /usr/X11/lib/amd64/

> * How about header files?
>  The header files are separated completely?
>  Or, the shareable headers are installed in /usr/include and
>  other arch-dependent headers are separated in other directories?
>  Or, system has only headers for most-suitable architechture?

As far as I've seen, most system headers exist in one copy only, and use 
preprocessor macros to detect which the architecture is; usually via 
<sys/isa_defs.h>, which defines macros for most of the interesting cases:

/*
 * This header file serves to group a set of well known defines and to
 * set these for each instruction set architecture.  These defines may
 * be divided into two groups;  characteristics of the processor and
 * implementation choices for Solaris on a processor.
 *
 * Processor Characteristics:
 *
 * _LITTLE_ENDIAN / _BIG_ENDIAN:
 *      The natural byte order of the processor.  A pointer to an int points
 *      to the least/most significant byte of that int.
 *
 * _STACK_GROWS_UPWARD / _STACK_GROWS_DOWNWARD:
 *      The processor specific direction of stack growth.  A push onto the
 *      stack increases/decreases the stack pointer, so it stores data at
 *      successively higher/lower addresses.  (Stackless machines ignored
 *      without regrets).
 *
 * _LONG_LONG_HTOL / _LONG_LONG_LTOH:
 *      A pointer to a long long points to the most/least significant long
 *      within that long long.
 *
 * _BIT_FIELDS_HTOL / _BIT_FIELDS_LTOH:
 *      The C compiler assigns bit fields from the high/low to the low/high end
 *      of an int (most to least significant vs. least to most significant).
 *
 * _IEEE_754:
 *      The processor (or supported implementations of the processor)
 *      supports the ieee-754 floating point standard.  No other floating
 *      point standards are supported (or significant).  Any other supported
 *      floating point formats are expected to be cased on the ISA processor
 *      symbol.
 *
 * _CHAR_IS_UNSIGNED / _CHAR_IS_SIGNED:
 *      The C Compiler implements objects of type `char' as `unsigned' or
 *      `signed' respectively.  This is really an implementation choice of
 *      the compiler writer, but it is specified in the ABI and tends to
 *      be uniform across compilers for an instruction set architecture.
 *      Hence, it has the properties of a processor characteristic.
 *
 * _CHAR_ALIGNMENT / _SHORT_ALIGNMENT / _INT_ALIGNMENT / _LONG_ALIGNMENT /
 * _LONG_LONG_ALIGNMENT / _DOUBLE_ALIGNMENT / _LONG_DOUBLE_ALIGNMENT /
 * _POINTER_ALIGNMENT / _FLOAT_ALIGNMENT:
 *      The ABI defines alignment requirements of each of the primitive
 *      object types.  Some, if not all, may be hardware requirements as
 *      well.  The values are expressed in "byte-alignment" units.
 *
 * _MAX_ALIGNMENT:
 *      The most stringent alignment requirement as specified by the ABI.
 *      Equal to the maximum of all the above _XXX_ALIGNMENT values.
 *
 * _ALIGNMENT_REQUIRED:
 *      True or false (1 or 0) whether or not the hardware requires the ABI
 *      alignment.
 *
 * _LONG_LONG_ALIGNMENT_32
 *      The 32-bit ABI supported by a 64-bit kernel may have different
 *      alignment requirements for primitive object types.  The value of this
 *      identifier is expressed in "byte-alignment" units.
 *
 * _HAVE_CPUID_INSN
 *      This indicates that the architecture supports the 'cpuid'
 *      instruction as defined by Intel.  (Intel allows other vendors
 *      to extend the instruction for their own purposes.)
 *
 *
 * Implementation Choices:
 *
 * _ILP32 / _LP64:
 *      This specifies the compiler data type implementation as specified in
 *      the relevant ABI.  The choice between these is strongly influenced
 *      by the underlying hardware, but is not absolutely tied to it.
 *      Currently only two data type models are supported:
 *
 *      _ILP32:
 *              Int/Long/Pointer are 32 bits.  This is the historical UNIX
 *              and Solaris implementation.  Due to its historical standing,
 *              this is the default case.
 *
 *      _LP64:
 *              Long/Pointer are 64 bits, Int is 32 bits.  This is the chosen
 *              implementation for 64-bit ABIs such as SPARC V9.
 *
 *      _I32LPx:
 *              A compilation environment where 'int' is 32-bit, and
 *              longs and pointers are simply the same size.
 *
 *      In all cases, Char is 8 bits and Short is 16 bits.
 *
 * _SUNOS_VTOC_8 / _SUNOS_VTOC_16 / _SVR4_VTOC_16:
 *      This specifies the form of the disk VTOC (or label):
 *
 *      _SUNOS_VTOC_8:
 *              This is a VTOC form which is upwardly compatible with the
 *              SunOS 4.x disk label and allows 8 partitions per disk.
 *
 *      _SUNOS_VTOC_16:
 *              In this format the incore vtoc image matches the ondisk
 *              version.  It allows 16 slices per disk, and is not
 *              compatible with the SunOS 4.x disk label.
 *
 *      Note that these are not the only two VTOC forms possible and
 *      additional forms may be added.  One possible form would be the
 *      SVr4 VTOC form.  The symbol for that is reserved now, although
 *      it is not implemented.
 *
 *      _SVR4_VTOC_16:
 *              This VTOC form is compatible with the System V Release 4
 *              VTOC (as implemented on the SVr4 Intel and 3b ports) with
 *              16 partitions per disk.
 *
 *
 * _DMA_USES_PHYSADDR / _DMA_USES_VIRTADDR
 *      This describes the type of addresses used by system DMA:
 *
 *      _DMA_USES_PHYSADDR:
 *              This type of DMA, used in the x86 implementation,
 *              requires physical addresses for DMA buffers.  The 24-bit
 *              addresses used by some legacy boards is the source of the
 *              "low-memory" (<16MB) requirement for some devices using DMA.
 *
 *      _DMA_USES_VIRTADDR:
 *              This method of DMA allows the use of virtual addresses for
 *              DMA transfers.
 *
 * _FIRMWARE_NEEDS_FDISK / _NO_FDISK_PRESENT
 *      This indicates the presence/absence of an fdisk table.
 *
 *      _FIRMWARE_NEEDS_FDISK
 *              The fdisk table is required by system firmware.  If present,
 *              it allows a disk to be subdivided into multiple fdisk
 *              partitions, each of which is equivalent to a separate,
 *              virtual disk.  This enables the co-existence of multiple
 *              operating systems on a shared hard disk.
 *
 *      _NO_FDISK_PRESENT
 *              If the fdisk table is absent, it is assumed that the entire
 *              media is allocated for a single operating system.
 *
 * _CONSOLE_OUTPUT_VIA_FIRMWARE / _CONSOLE_OUTPUT_VIA_SOFTWARE
 *      This indicates whether framebuffer console output is done by
 *      firmware or software.
 *
 *      _CONSOLE_OUTPUT_VIA_FIRMWARE
 *              Framebuffer console output is done via prom_* calls.
 *
 *      _CONSOLE_OUTPUT_VIA_SOFTWARE
 *              Framebuffer console output is done via the software
 *              terminal emulator.
 *      _DONT_USE_1275_GENERIC_NAMES
 *              Controls whether or not device tree node names should
 *              comply with the IEEE 1275 "Generic Names" Recommended
 *              Practice. With _DONT_USE_GENERIC_NAMES, device-specific
 *              names identifying the particular device will be used.
 *
 * __i386_COMPAT
 *      This indicates whether the i386 ABI is supported as a *non-native*
 *      mode for the platform.  When this symbol is defined:
 *      -       32-bit xstat-style system calls are enabled
 *      -       32-bit xmknod-style system calls are enabled
 *      -       32-bit system calls use i386 sizes -and- alignments
 *
 *      Note that this is NOT defined for the i386 native environment!
 *
 * __x86
 *      This is ONLY a synonym for defined(__i386) || defined(__amd64)
 *      which is useful only insofar as these two architectures share
 *      common attributes.  Analogous to __sparc.
 *
 * _PSM_MODULES
 *      This indicates whether or not the implementation uses PSM
 *      modules for processor support, reading /etc/mach from inside
 *      the kernel to extract a list.
 *
 * _RTC_CONFIG
 *      This indicates whether or not the implementation uses /etc/rtc_config
 *      to configure the real-time clock in the kernel.
 */

A typical ABI-dependent headerfile would then include <sys/isa_defs.h>, 
and use the presence of either of _ILP32 and _LP64 (and possibly 
_LITTLE_ENDIAN/_BIG_ENDIAN (consider eg ppc which supports both)).

A few system headers use architecture dependent directories. eg:

  $ ls -lFR /usr/include/amd64
  /usr/include/amd64:
  total 2
  drwxr-xr-x   2 root     bin          512 May  4  2005 sys/

  /usr/include/amd64/sys:
  total 16
  -rw-r--r--   1 root     bin         7189 Jan 21  2005 privregs.h

> Regards,
> mpsuzuki
>
> P.S.: Hey, any guys on IRIX, AIX and HP-UX?

IRIX/MIPS has three ABIs; o32, n32 and n64, where o32 probably can be 
regarded as obsolete. I don't have access to any IRIX systems anymore, but 
if I remember correctly they had a filesystem organization similar to 
that of Solaris.

My AIX 5L/ia64 (anybody else have one?) system is currently down, but as 
far as I remember its compilation environment only supported a single ABI.

I've never had access to any 64-bit capable AIX/POWER or HPUX/HPPA
systems.

--
Henrik Grubbström                                       address@hidden
Roxen Internet Software AB