7

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

Robocide
  • 6,353
  • 4
  • 37
  • 41

5 Answers5

4

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.

Community
  • 1
  • 1
David
  • 5,356
  • 2
  • 26
  • 39
  • i'm familiar with these guides, but the question is , if there is any tool which can save human work hours and is it suffice ? instead of search for thousands of suspicious places in code .... – Robocide Aug 24 '10 at 15:29
  • Hi, I have similar problem of porting 32 code to 64-bit architecture. If I compile with "gcc -m32" will the porting to 64-bit expected to be transparent ? – ransh Feb 19 '15 at 12:19
4

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.

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
Jens Gustedt
  • 76,821
  • 6
  • 102
  • 177
  • that maybe good , but i'm not sure it covers all pitfalls.... im searching for a tool which covers all pitfalls in order to reduce run-time errors .... – Robocide Aug 24 '10 at 15:31
  • 1
    @_Avishay_: sure there are others, but I really think that these are the main ones, generally implicit integer promotions are the rest of it. Also sure, if the code is badly written, this will give you tons of results, but each pointing to a potential trouble spot. You wouldn't be safe if you'd not resolve them all in any case. And also sure that this will be hard to guess sometimes, since using just `int` for example simply lacks the semantic tags any automatic tool would need... I personally don't believe in the existence of tools that transform bad code into good one. – Jens Gustedt Aug 24 '10 at 15:48
  • i'm not searching for a tool to transfer it from unportable code to portable code , thats quite hard for a auto tool , but it seems its easier for a tool to search for unportable places in code that maybe compiler wanning will not find.... – Robocide Aug 25 '10 at 07:42
  • @_Avishay_: I don't agree. Asking to port from 32 bit to 64 bit, is in much respect the same as asking to transfer unportable code to portable. The `grep` that I gave gives you a lot of trouble spots for that. For the rest, e.g explicit casts or integer promotions, they are part of the language, and no tool will be able to tell whether or not they are intentional or not. – Jens Gustedt Aug 25 '10 at 09:33
  • Hi, I have similar problem of porting 32 code to 64-bit architecture. If I compile with "gcc -m32" will the porting to 64-bit expected to be transparent ? – ransh Feb 19 '15 at 12:19
  • @ransh, please don't post comments on a question that is 5 years old. If you have a real question for SO ask it the usual way. – Jens Gustedt Feb 19 '15 at 13:54
1

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.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • what about run-time errors ? do you absolutely trust compiler warnnings for this issue ? i doubt it. – Robocide Aug 24 '10 at 15:12
  • 6
    It's too easy to fall into the non-portable trap, even simple stuff like sprintf("%u",sizeof something); will bite you, In my experience , large scale apps have been often been developed over decade, with too many people messing around, and you'll never know what'll explode when you compile/run it on something else than it has ever run – nos Aug 24 '10 at 15:14
  • 8
    Ah, programming in a truly unportable manner, that's easy... casting pointers to `int`, having implicit integer propagation when using `va_arg` functions, having seemingly constants change their signedness... don't worry. – Jens Gustedt Aug 24 '10 at 15:16
  • what you guys says actually emphasize that re-compiling for 64 bits is just not enough.... – Robocide Aug 24 '10 at 15:30
  • Why don't you actually try it? – Dirk Eddelbuettel Aug 24 '10 at 16:06
  • 1
    ofcourse i will, i will also regard to warnnings of compilers, what i'm searching if there is any TOOL that can asist of finding not fixing finding suspicous places to be fixed. – Robocide Aug 25 '10 at 07:41
  • Hi Dirk, compiling with "gcc -m32" is expected to result in transparent porting for the 64-bit architecture ? – ransh Feb 19 '15 at 12:20
1

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

Alex F
  • 42,307
  • 41
  • 144
  • 212
  • do you know that not every application can be ported to 64 bits with just re-compiling ? do you know there are allot of issues that can cause problems in run-time and not in compile time ?? – Robocide Aug 24 '10 at 15:11
  • 1
    Agree, but the first step to do is still to compile... Most of incorrect stuff is not compiled, like assigning a pointers to 32-bit integer values, or different int and size_t size. – Alex F Aug 24 '10 at 15:22
  • 2
    and crank up the warning level: `-pedantic -Wall -Wextra` is a good start. It'll *help* you find some issues. Of course, there is no tool that I know of that will correct your assumptions of certain data types, alignment, assembly and whatnot. That's just to complicated. – rubenvb Aug 24 '10 at 16:41
0

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.

phuclv
  • 37,963
  • 15
  • 156
  • 475
mg63
  • 1