Linux Workstation Processor Compiling FAQ

What is this "AMD64" and or "EMT64" stuff all about?

"AMD64" is the name given to AMD's 64-bit line of x86-compatible processors. The AMD64 processors are commonly referred to as "Opteron" processors; however, "Opteron" is a specific model of processor in the line. The AMD64 processors support both existing 32-bit x86 applications as well as 64-bit x86_64 applications. Intel has finally decided to join AMD in offering 64 bit x86-compatible processors as well and their marketing name is called "EMT64". Currently, all lab computers are 64 bit, though many TA, RA, and Faculty machines remain 32 bit.

What do "x86" and "x86_64" mean?

In short, "x86" => 32-bit, "x86_64" => 64-bit.

"x86" and "x86_64" are instructions sets, the low-level set of instructions that a particular processor understands. x86 is the "standard" Intel 32-bit instruction set used by Intel, AMD, Transmeta, Via, and several other processor vendors. x86_64 is AMD's (and now Intel's) set of extensions to the x86 instruction set. The extensions give the standard x86 instruction set 64-bit capabilities, while not sacrificing backwards compatibility with the de facto x86 instruction set.

How do I determine if the machine is 32 or 64 bit?

The command uname -p will tell you the processor type of a machine. On a 64-bit machine it will output x86_64. On a 32-bit machine, it will likely output i686; though it may output i386, i486 or i586.

Why are the AMD64/EMT64 processors better than standard 32-bit AMD/Intel processors?

Following are a few of the reasons:

64-bits allows 64-bits of address space, which means the 4GB 32-bit memory barrier is no longer existent
On-chip memory controller (for the AMD line of proc's only)
More on-chip L1/L2 cache
AMD's "HyperTransport" high-speed bus connections to other board components (AGP subsystem, north/south bridges, etc.)

Can I run 32-bit applications on the AMD64/EMT64 machines? How about 64-bit applications on the 32-bit machines?

32-bit applications on 64-bit (AMD64/EMT64) machines can be run if the following are satisfied:

All of the 32-bit libraries that the program needs are installed on the AMD64/EMT64 machine. 32-bit apps can't link against 64-bit libraries. If this is an issue, compile all programs statically to eliminate the need for runtime library dependencies.
No assumptions are made that rely on 32-bit kernel parameters, overflows, or timers.

64-bit (AMD64) applications on 32-bit machines can never be run. The 32-bit processors simply don't have the capabilities.

What are the technical limits imposed by the Linux kernel, the AMD64 processor, and the RHEL load?

See /usr/share/doc/kernel-doc-*/Documentation/x86_64/mm.txt on any AMD64 Linux machine for more details:

Per process virtual address space limit of 512 Gigabytes
Top of userspace stack located at address 0x0000007fffffffff
Start of the kernel mapping = 0x0000010000000000
Possible global RAM per system 508*512GB=254 Terabytes
512GB of vmalloc/ioremap space

How to I compile 32/64 -bit applications on 32/64 -bit processors using gcc?

There are four seemingly possible combinations:

Build 32-bit applications on a 32-bit machine
This is the default action. No special compiler options are necessary.
Build 32-bit applications on a 64-bit machine
This can be accomplished with the -m32 option to gcc.
Build 64-bit applications on a 64-bit machine
This is the default action. No special compiler options are necessary.
Build 64-bit applications on a 32-bit machine
This is not possible.

How is runtime library loading handled? Where are the 32/64 -bit libraries located?

Runtime library loading, commonly referred to as dynamic linking, gives a program the ability to load a library at runtime, rather than at compile-time. The dlopen(), dlclose(), etc., family of C-language calls are used in this process. The issue on the AMD64/EMT64 machines is that both 32-bit and 64-bit libraries can be loaded by the dynamic linking loader. For this reason, a few common-sense best practices should be followed:

32-bit libraries are stored in the standard locations: "/lib" and "/usr/lib".
64-bit libraries are stored in the following locations: "/lib64" and "/usr/lib64".
As a Linux/OSS convention, 64-bit libraries are stored exactly as 32-bit libraries, except instances of "lib" in the library path are replaced with "lib64". The convention should be used when creating new libraries or applications as well.
Never try to link a 32-bit application against 64-bit libraries, either statically or dynamically.
Never try to link a 64-bit application against 32-bit libraries, either statically or dynamically.

How do I know if a program or library is 32-bit or 64-bit?

The file command can be used to find out if a program or library is 32-bit or 64-bit. See man file for more information.

Example: A sample compilation/run of a simple "helloworld" program.

First, we have some source code:

[hawkid@l-lnx133]$ ls -l
total 8
-rw-r--r-- 1 hawkid csg 75 Apr 30 10:07 helloworld.c

[hawkid@l-lnx133]$ cat helloworld.c
#include

int main ()
{
printf("Hello World!\n");
return 0;
}

We can see that we're on an AMD64/EMT64 machine:

[hawkid@l-lnx133]$ uname -a
Linux l-lnx133.divms.uiowa.edu 2.4.21-9.EL #1 Thu Jan 8 16:58:25 EST 2004 x86_64 x86_64 x86_64 GNU/Linux

Next, we build 32-bit and 64-bit versions of the program, both statically and dynamically. Use the compile option -Wall to turn on all warnings:

[hawkid@l-lnx133]$ gcc -Wall helloworld.c -o helloworld-64-dynamic

[hawkid@l-lnx133]$ gcc -Wall -static helloworld.c -o helloworld-64-static

[hawkid@l-lnx133]$ gcc -Wall -m32 helloworld.c -o helloworld-32-dynamic

[hawkid@l-lnx133]$ gcc -Wall -m32 -static helloworld.c -o helloworld-32-static

As expected, the executable programs are of different sizes, with the statically compiled executables being significantly larger:

[hawkid@l-lnx133]$ ls -l
total 928
-rwxr-xr-x 1 hawkid csg 4703 Apr 30 10:47 helloworld-32-dynamic
-rwxr-xr-x 1 hawkid csg 412373 Apr 30 10:47 helloworld-32-static
-rwxr-xr-x 1 hawkid csg 6828 Apr 30 10:46 helloworld-64-dynamic
-rwxr-xr-x 1 hawkid csg 487617 Apr 30 10:46 helloworld-64-static
-rw-r--r-- 1 hawkid csg 75 Apr 30 10:07 helloworld.c

The file command verifies that our compilations created the executables as we had intended:

[hawkid@l-lnx133]$ file helloworld-32-dynamic
helloworld-32-dynamic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

[hawkid@l-lnx133]$ file helloworld-32-static
helloworld-32-static: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, statically linked, not stripped

[hawkid@l-lnx133]$ file helloworld-64-dynamic
helloworld-64-dynamic: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped

[hawkid@l-lnx133]$ file helloworld-64-static
helloworld-64-static: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, statically linked, not stripped

Finally, we run each of the executables to verify that they all run exactly the same:

[hawkid@l-lnx133]$ ./helloworld-32-dynamic
Hello World!

[hawkid@l-lnx133]$ ./helloworld-32-static
Hello World!

[hawkid@l-lnx133]$ ./helloworld-64-dynamic
Hello World!

[hawkid@l-lnx133]$ ./helloworld-64-static
Hello World!

What should happen if we were to try to run either of the 64-bit executables on a 32-bit machine?

[hawkid@a-lnx000]$ uname -a
Linux a-lnx000.divms.uiowa.edu 2.4.21-9.0.3.ELsmp #1 SMP Tue Apr 20 19:49:13 EDT 2004 i686 i686 i386 GNU/Linux

[hawkid@a-lnx000]$ ls -l
total 928
-rwxr-xr-x 1 hawkid csg 4703 Apr 30 10:47 helloworld-32-dynamic
-rwxr-xr-x 1 hawkid csg 412373 Apr 30 10:47 helloworld-32-static
-rwxr-xr-x 1 hawkid csg 6828 Apr 30 10:46 helloworld-64-dynamic
-rwxr-xr-x 1 hawkid csg 487617 Apr 30 10:46 helloworld-64-static
-rw-r--r-- 1 hawkid csg 75 Apr 30 10:07 helloworld.c

[hawkid@a-lnx000]$ ./helloworld-32-dynamic
Hello World!

[hawkid@a-lnx000]$ ./helloworld-32-static
Hello World!

[hawkid@a-lnx000]$ ./helloworld-64-dynamic
bash: ./helloworld-64-dynamic: cannot execute binary file

[hawkid@a-lnx000]$ ./helloworld-64-static
bash: ./helloworld-64-static: cannot execute binary file

As expected, 64-bit executables will not run on 32-bit machines.

Where can I go for more information about C?

The website http://c-faq.com has a collection of frequently asked questions. The website http://gcc.gnu.org/faq.html has a collection of frequently asked questions for GCC.
Most C functions have a man page (short for manual page) that can be viewed by typing man 3 functionname. For example, man 3 printf will give you information about the printf family of functions.
If you need a reference for gcc's many options, you can read the man page for gcc by typing man gcc.
Your TA or instructor. The CLAS Linux Group team is not a resource for debugging your code, however we do maintain the compilers and computing environment. Maintenance issues of the compiler or environment (like the compiler won't compile the hello world program above) are valid questions.

Are there any commercial compilers available like Intel?

The CLAS Linux Group staff maintain Intel Compilers in additions to the GNU compilers. The Intel compilers can be installed by request (due to the amount of space they take to install).