ABIs support on Linux

[hjl@lucon.org (H.J. Lu)]

> 
> On Tue, 20 Apr 1999, David Miller wrote:
> 
> >    > I wonder how a Merced userland is going to work if we wish to
> >    > allow people to still compile 32-bit x86 binaries, even though
> >    > the instruction set is radically different between the two.
> > 
> >    Merced running i386 binaries is still stricly emulation, I believe,
> >    so I'd see that as cross-compilation, rather than multiple ABIs.
> > 
> > I think it's still more of a gray area than this.  The x86
> > instructions will execute natively on the processor, so in this
> > light using your analysis we could say that executing 32-bit Sparc
> > binaries on UltraSparc cpus is emulation and that compiling such
> > 32-bit Sparc binaries would be cross-compilation. :-)
> 
> But it's (probably :) a completely different instruction set, which I
> don't think is the case with sparc/sparc64.
> 

Running i386 binaries on Merced is not the problem. The problems are

1. How do you compile i386 binaries on Merced?
2. How do you compile Merced binaries on Merced?
3. How do you install the existing i386 binary packages on Merced?
4. How do you install the new Merced binaries on Merced?

> Unless I'm missing something, the ABI defines calling conventions, sizes
> of basic types, &c., rather than the actual instruction set.
> 
> I suppose it's slightly grey in the case that both instruction sets are
> "native", but it's basically a completely different toolchain, so
> -m(merced|ix86) doesn't make much sense to me..
> 

The compiler is not the problem. The problem is how you put together
a complete Linux system supporting both i386 and Merced at the same
time.

As Linux moves to new platforms with both 32bit and 64bit ABIs, we now
face the problem to support 2 different ABIs at the same time. There
are different levels of support for 2 ABIs. We need to define our
goals first. There are 2 categories of approaches:

1. Choose 64bit as the  native ABI for the platform, support both
compile and run-time environments for the native ABI. For the 32bit ABI,
only the run-time environment is provided by default. The compile
environment for the 32bit ABI is implemented as a cross-compile system.

  Pros:
    A. Minimal change to the existing 64bit clean source code base.
    B. Encourage migration to the 64bit ABI.

  Cons:
    A. If the source code is not 64bit clean and it is very hard to
    clean up due to various reasons, you have to compile it on the
    32bit platform or cross-compile it on the new platform. For a
    complex package which depends on many other 32bit packages, it may
    be a problem.
    B. It is not easy to install the precompiled 32bit binary package
    on the platform with the 64bit native ABI. If the package has its
    own 32bit development and/or run-time systems, it makes things even
    worse.

2. Both 32bit and 64bit ABIs are both native for the platform, support
both compile and run-time environments for 2 ABIs. The compile and
run-time environments can be made backward compatible with the 32bit
ABI.

  Pros:
    A. No change to the existing 32bit source code.
    B. Easy to install, most if not all, existing 32bit binary packages,
    including those with their own 32bit development and/or run-time
    systems.

  Cons:
    A. May require massive change to the existing source code base
    to use the 64bit ABI even if the source code is 64bit clean. Since
    most of the Linux softwares are available in the source form, it
    may benefit mostly commercial ISVs who want to keep using the 32bit
    ABI on the 64bit platform.
    B. Delay migration to the 64bit ABI.
   
Personally I prefer #1. But it will be a problem for those commercial
ISVs whose sources are not 64bit clean or they don't want to make 2
versions of the same product due to support and test. Whatever we
do, we have to decide now since the decision we make may affect many
Linux software developers, commercial or non-commercial. The earlier
they know, the better they can prepare.

Thanks.


H.J.