porting linux 32 bit app to 64 bit?

Question

i'm about to port very large scale application to 64 Bits, i've noticed in that in the web there some articles which shows many pitfalls of this porting , i wondered if there is any tool which can assist in porting to 64 bit , meaning finding the places in code that needs to be changed.... maybe the gcc with warnnings enabled... is it good enough ? is there anything better ?

EDIT: Guys i am searching for a tool if any that might be a complete to the compiler, i know GCC can asist , but i doubt it will find all un portable problems that
will be discovered in run-time....maybe static code analysis tool that emphasize porting to 64 bits ?

thanks

Answer 1

Here is a link to an Oracle webpage that talks about issues commonly encountered porting a 32bit application to 64bit:

http://www.oracle.com/technetwork/server-storage/solaris/ilp32tolp64issues-137107.html

One section talks how to use lint to detect some common errors. Here is a copy of that section:

Use the lint Utility to Detect Problems with 64-bit long and Pointer Types Use lint to check code that is written for both the 32-bit and the 64-bit compilation environment. Specify the -errchk=longptr64 option to generate LP64 warnings. Also use the -errchk=longptr64 flag which checks portability to an environment for which the size of long integers and pointers is 64 bits and the size of plain integers is 32 bits. The -errchk=longptr64 flag checks assignments of pointer expressions and long integer expressions to plain integers, even when explicit casts are used.

Use the -errchk=longptr64,signext option to find code where the normal ISO C value-preserving rules allow the extension of the sign of a signed-integral value in an expression of unsigned-integral type. Use the -m64 option of lint when you want to check code that you intend to run in the Solaris 64-bit SPARC or x86 64-bit environment.

When lint generates warnings, it prints the line number of the offending code, a message that describes the problem, and whether or not a pointer is involved. The warning message also indicates the sizes of the involved data types. When you know a pointer is involved and you know the size of the data types, you can find specific 64-bit problems and avoid the pre-existing problems between 32-bit and smaller types.

You can suppress the warning for a given line of code by placing a comment of the form "NOTE(LINTED())" on the previous line. This is useful when you want lint to ignore certain lines of code such as casts and assignments. Exercise extreme care when you use the "NOTE(LINTED())" comment because it can mask real problems. When you use NOTE, also include #include. Refer to the lint man page for more information.

Answer 2

A good tool is called grep ;-) do

grep -nH -e '\<int\>\|\<short\>\|\<long\>' *

and replace all bare uses of these basic integer types by the proper one:

• array indices should be size_t
• pointer casts should be uintptr_t
• pointer differences should be prtdiff_t
• types with an assumption of width N should be uintN_t

and so on, I probably forgot some. Then gcc with all warnings on will tell you. You could also use clang as a compiler it gives even more diagnostics.

Answer 3

Here's a guide. Another one

Size of some data types are different in 32-bit and 64-bit OS, so check for place where the code is assuming the size of data types. eg If you were casting a pointer to an int, that won't work in 64bit. This should fix most of the issues.

If your app uses third-party libraries, make sure those work in 64-bit too.

Answer 4

What about compiling the project in 64 bits OS? gcc compiler looks like such tool :)

Answer 5

First off, why would there be 'porting'?

Consider that most distros have merrily provided 32 and 64 bit variants for well over a decade. So unless you programmed in truly unportable manner (and you almost have to try) you should be fine.