3

We are porting from 32 Bit to LP64 with gcc/linux. I am looking for a method to track the usage of the datatypes that change in memory layout(long,Ptr). I'm interested in the loaction of all possible problematic "interactions" with these types.

Typedefs need to be dereferenced to builtin types like ULONG and DWORD -> unsigned long Possible problems may be i.E.: old-Style cast, reinterpret-cast, arithmetic, over/underflow, assignment, comparison, constants, ptr arithmetics, sizeof, size_t arithmetics,implicit conversation... younameit.

Because this is not a trivial thing to do with regexp and the codebase is huge, i need to automate it somehow. I think i need at least a parse tree / AST along with a symbol table. i tried some of the GCC's internal tree dumps at various stages but still have no clue. i also enabled all warnings the compiler has to offer about this ;-) Maybe anyone can give me a hint where to look for. (i allready saw this semantic design Toolokit which looks promising)

How did you do it? Try, test, fail and deal with the errors? I'll give clang a try...

Regards

  • This is preferably done using `libclang` and the `clang` toolchain/ecosystem. I haven't heard of anyone writing C++ toolings based on gcc ASTs, and while those may exist, `clang` AST visiting is definitely what you want to look at. – Max Langhof Dec 12 '19 at 14:53
  • In C++, "atomic types" generally would mean `std::atomic<>`. I think you mean something else. Also, you state that you're porting to LLP64 but then claim that `long` changes to 64 bits. That's wrong, in LLP64 `long` stays at 32 bits. The 64 bits types are `long long` and pointer, hence the LLP. – MSalters Dec 12 '19 at 16:17
  • @MSalters as you suspected, i meant builtin C primitives ;-) int,char,short,long,float,double. In my case long and Ptr change from 4 to 8 bytes. so it's LP64 then... Updated the question. –  Dec 13 '19 at 08:28

2 Answers2

5

If possible, avoid thinking of it as "LLP64" specifically, and use the datatypes provided (uintptr_t, size_t, etc.), might as well have code that should be correct elsewhere. Especially do not assume long is 64bits.

I think i need at least a parse tree / AST along with a symbol table.

I don't believe a perfect solution exists, there are already static analysis tools available you can search for can use to catch many possible errors, but some things still get past and the sensitivity level needed to detect some of them can give a lot of false positives.

Compilers can detect the basic ones you will easily find with your own parser, for example:

auto x = (SomeTypeDefedThing)*some_pointer;
int y = some_long;

warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion]

Explicit integers conversions are a bigger problem, if you have a x = (int)y or x = (long)y, etc., the compiler just assumes you meant that conversion, and determining if y can be out of range is really tricky.

While you might be able to find this in static analysis, I expect such a warning to be very noisy, as such an explicit conversion normally really did want to do that.

If you are doing any binary file or network IO, that can be a problem. Ideally it will have been written with the types already provided to work correctly between different implementations. Such code can take many forms and be hard to simply search for, but if you know your program does do such file or network things, it should be easy to identify and check manually.

If you really need to look for a specific pattern that is very common in your code, but not detected by pre-existing compilers and static analysis tools, then maybe putting together your own can help.

Clang provides a number of useful libraries and tools to look at. While GCC (and other toolchains like MSVC) probably have intermediate file formats you can parse, I have not seen them used and seems to be far less documentation (if complete at all) on those.

They have an introduction doc, and you can get the ast by compiling with -ast-dump. https://clang.llvm.org/docs/IntroductionToTheClangAST.html

Fire Lancer
  • 29,364
  • 31
  • 116
  • 182
0

For correct porting:

  1. Read Lessons on development of 64-bit C and C++ applications.
  2. Try PVS-Studio diagnostics (the 64-bit rule set) (free license).
AndreyKarpov
  • 1,083
  • 6
  • 17