bpo-30345: Add -g to LDFLAGS to ease debug

[vstinner]

When using PGO+LTO and compile without LDFLAGS=-g, gdb fails to get
function arguments: add -g to LDFLAGS to ease debug.

https://bugs.python.org/issue30345

[vstinner]

cc @Traceur759

[vstinner]

Hum, who can review this change? :-) @pitrou @ned-deily @serhiy-storchaka @methane @doko42 modified configure.ac recently. Also @encukou maybe?

[serhiy-storchaka]

Shouldn't it be added only in debug mode? I afraid that adding -g in release mode can disable some optimizations.

[vstinner]

We already always pass -g to CFLAGS, even in release mode.

Extract of gcc manual page:

       -g  Produce debugging information in the operating system's native
           format (stabs, COFF, XCOFF, or DWARF).  GDB can work with this
           debugging information.

           On most systems that use stabs format, -g enables use of extra
           debugging information that only GDB can use; this extra information
           makes debugging work better in GDB but probably makes other
           debuggers crash or refuse to read the program.  If you want to
           control for certain whether to generate the extra information, use
           -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).

It's unrelated to optimizations. It's just an option to ask to include also debug symbols in the produced binary file (like ELF file on Linux).

If you want to get ride of them, just run "strip python". Linux vendors are able to distribute these debug symbols in a different package, like python-debuginfo on Fedora.

I'm not 100% sure, that's why I'm asking for a review :-)

[serhiy-storchaka]

Thank you, now I got this.

[pitrou]

I think it's ok to add -g to link flags, I just don't understand why it's added in a single code path in configure.ac.
(also, what exactly is $ac_cv_prog_cc_g?)

[methane]

AFAIK, -g is required only when LTO because code generation is happen in link time.
So I think it's safer that adding -g here in configure.ac.

   CFLAGS="$CFLAGS $LTOFLAGS"
-  LDFLAGS="$LDFLAGS $LTOFLAGS"
+  LDFLAGS="$LDFLAGS -g $LTOFLAGS"

LINKCC is CC for most case, but not always.

[methane]

(also, what exactly is $ac_cv_prog_cc_g?)

I think it means whether CC supports -g or not. And we use CC for LINKCC by default on most platform. (except AIX).

[vstinner]

"AFAIK, -g is required only when LTO because code generation is happen in link time. So I think it's safer that adding -g here in configure.ac."

Done.

[vstinner]

"(also, what exactly is $ac_cv_prog_cc_g?) I think it means whether CC supports -g or not."

Hum, why, I cannot add -g for all platforms?

[methane]

I don't know linker without -g support.
If AIX supports -g, I feel worrying about minor linker/platform is worthless.

[vstinner]

I modified my PR to respect $ac_cv_prog_cc_g.

[methane]

I'm sorry, I meant why ac_cv_prog_cc_g is used in general.

LTO is used only with clang and gcc. So no need to worry about others when adding -g only with LTO.

[methane]

I'm OK to merge this with or without $ac_cv_prog_cc_g check.

[miss-islington]

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6.
🐍🍒⛏🤖

[miss-islington]

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

[miss-islington]

Sorry, @vstinner, I could not cleanly backport this to 3.6 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 06fe77a84bd29d51506ab2ff703ae585a6121af2 3.6

[bedevere-bot]

GH-7824 is a backport of this pull request to the 3.7 branch.

[bedevere-bot]

GH-7826 is a backport of this pull request to the 3.6 branch.