This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
ABIs support on Linux
- To: davem@redhat.com, weejock@ferret.lmh.ox.ac.uk
- Subject: ABIs support on Linux
- From: hjl@lucon.org (H.J. Lu)
- Date: Tue, 20 Apr 1999 19:07:21 -0700 (PDT)
- Cc: egcs@egcs.cygnus.com, libc-hacker@cygnus.com (GNU C Library)
>
> 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.