ABINIT Discussion Forums

Dear Developers,

In order to facilitate the debugging of new developments, Matthieu and I are proposing to have different debug levels in the build system, controlled by --enable-debug:

• no: debugging fully disabled;
• yes: debug symbols are provided;
• enhanced: more sensible warnings are enabled;
• paranoid: array bound checks, et c.

Matthieu proposes that debug flags be incremental, i.e. a specific level receives all flags from the previous ones plus a few more.

Do not hesitate to provide comments and suggestions. If I receive no strong opposition in the coming weeks, I will consider this proposal as a specification and implement it.

This idea sounds good (isn't it already partly implemented ?).

The question is now: which level choose as default ?
yes= is the current level;
it is useful to quickly find source of problems without recompiling, but the size of the excecutable increases;
and what about the performances (I have no idea) ?

Marc

Fine with me.

I have no idea about the effect of -g on the performance.
I usually keep the -g option, but it's normal as I have to
fix the zillion of bugs I usually introduce in the code

On the other hand, it's worth considering the possibility of using "no" as default
if we find that removing -g leads to some speed-up either at the level of the compilation or at run-time,

A question maybe a bit off-topic. It is really useful
to use -g by default even at high level of optimization in which
the compiler is allowed to perform deep changes in the
structure of the loops?
I would never trust the output of a debugger when the executable has been generated with -O3!

Debugging symbols do not affect the performance of the code, nor its memory footprint, as they are not loaded in normal runs. They only impact the size of the binary.

However, it is true that the more you optimize, the less using debugging symbols is relevant. In practice, it nevertheless provides interesting information in most cases. Quoting the GCC manual:

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops. Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

Some people even think that it is stupid to strip executables. Personally I always use debugging symbols.