In Python 2.7, when using ./configure --with-pydebug, Python is built using -O0 compiler optimization level: disable all optimizations. The comment is quite explicit: "Optimization messes up debuggers, so turn it off for debug builds".

if test "$Py_DEBUG" = 'true' ; then
    # Optimization messes up debuggers, so turn it off for
    # debug builds.
    OPT="-g -O0 -Wall $STRICT_PROTO"
else
    OPT="-g $WRAP -O3 -Wall $STRICT_PROTO"
fi

In Python 3, -Og is preferred over -O0 for pydebug, if -Og is available:

if test "$Py_DEBUG" = 'true' ; then
    # Optimization messes up debuggers, so turn it off for
    # debug builds.
    if "$CC" -v --help 2>/dev/null |grep -- -Og > /dev/null; then
        OPT="-g -Og -Wall"
    else
        OPT="-g -O0 -Wall"
    fi
else
    OPT="-g $WRAP -O3 -Wall"
fi

Problem: in my experience, gdb traceback doesn't make sense sometimes, and gdb fails to inspect some function arguments and some variables which are displayed as <optimized out>.

See a very concrete example with a test_gdb failure on x86-64 when Python is compiled using gcc -Og:
https://bugzilla.redhat.com/show_bug.cgi?id=1734327#c22

My colleague who is working on gdb suggests to use -O0:
https://bugzilla.redhat.com/show_bug.cgi?id=1734327#c27

Since I started contributing to Python, I always forced gcc -O0 because any other optimization level caused me many issues in gdb. I'm using -O0 for 10 years with sucess.

The GCC documentation says "It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0." But my experience says the opposite.

Note: instead of -g, we could use -g3 to include debug information for macros and defines.

--

I'm proposing to change the *default* compiler flags from -Og to -O0. Obviously, Linux distributions and developers are free to override the compiler optimization level. For example: ./configure --with-pydebug CFLAGS="-Og" ensures that Python is always built using -Og.

I propose to modify 3.7, 3.8 and master branches.

I basically propose to revert bpo-23445 change:

commit 3d6c784371bccc2407048652bce50c5bccf9b1af
Author: Antoine Pitrou <solipsis@pitrou.net>
Date:   Wed Feb 11 19:39:16 2015 +0100

    Issue #23445: pydebug builds now use "gcc -Og" where possible, to make the resulting executable faster.

test_gdb is failing in different architectures and different operating systems:

* Fedora, Python 3.8, x86-64:
  https://bugzilla.redhat.com/show_bug.cgi?id=1734327

* RHEL8, Python 3.6, s390x
  https://bugzilla.redhat.com/show_bug.cgi?id=1712977

* RHEL 8, Python 3.6, ppc64le
  https://bugzilla.redhat.com/show_bug.cgi?id=1714733

I'm quite sure that most issues are caused by the compiler optimization level which is not -O0.

See also bpo-37631: the debug build of the RHEL8 package is supposed to be compiled using -O0 using EXTRA_CFLAGS variable, but -O0 in EXTRA_CFLAGS variable is overriden by -02 in CFLAGS_NODIST.

My use case is to debug a crash using a Python compiled in debug module, like python3-debug program in Fedora. Since the debug ABI is now compatible with the release build, the idea is to attempt to reproduce a crash in gdb using python3-debug instead of python3, and then use gdb to see what's going on.

With -Og, the call stack is wrong sometimes, and some function arguments and local variables cannot be read (displayed as <optimized out>).

On Travis CI, a few months ago, Python was built in debug mode using -O3. But it was a side effect of OpenSSL flags if I recall correctly.

With my PR 16544, Travis CI now uses -O0.

Do note though that if the -D_FORTIFY_SOURCE=2 hardening flag is used, the compilation will fail with an optimization level less than -Og.

Haven't tried yet with -D_FORTIFY_SOURCE=1 to see if it works with -O0.

Correction, not fail, just a ton of warnings. The same is true for -D_FORTIFY_SOURCE=1

If -Og is breaking debugging, isn't that a compiler bug? The GCC manpage claims " -Og enables optimizations that do not interfere with debugging."

It seems that it's still being worked on from gcc's side:

https://gcc.gnu.org/bugzilla//show_bug.cgi?id=78685

> Do note though that if the -D_FORTIFY_SOURCE=2 hardening flag is used, the compilation will fail with an optimization level less than -Og.

Does it make any sense to use a debug build in production? Does it make sense to enable hardening on a debug buil?d

The purpose of using -Og is that it significantly speeds up tests. You can always pass CFLAGS="-O0" if you debug particular debugger issues, but in normal cases -Og looks more beneficial. It saves hours of time of common developers.

There consensus seems to be towards the status quo: -Og is a good trade off between debug and performance for most core developers usage.

For the Fedora package, it may make sense to use -O0, but that should be discussed in Fedora ;-)

So I close the issue. Thanks for the interesting discussion :-)

See also bpo-40019: "test_gdb  should better detect when Python is optimized".