@hgy59 I've been looking for a solution of this kind since quite a while: the ability to "easily" generate debug_info packages so it becomes more obvious debugging them when getting segfault core-dumps using gdb.

As this is exactly what's hapening with libtorrent on DSM6, this PR also became a first attempt at doing so by adding a GCC_DEBUG system-wide variable that you can set as needed such as GCC_DEBUG = -O0 -g3 (wich is pretty much the standard from my understanding).

Your thoughts on it would be appreciated. I find this intrusive for cross/* dependencies that add -O flags. An other approach could the to look for -O flags within ADDITIONAL_CFLAGS and auto-magically removing them? Perhaps you might think of a slightly different approach more (un)optimized?

EDIT: I was able to find an alternate approach which makes this way more convenient. From spksrc.cross-env.mk it re-adjust the ADDITIONAL_C*FLAGS variables to strip any -O* option and add -O0 -g3 as gcc debug flags. This alleviate entirely the need to play with individual cross/Makefile as everything is lefts as is. The only thing needed is to set GCC_DEBUG_INFO := 1 in the needed build. In turn, up the wheel builds are being affected by this such as:

$ file _cffi_backend.cpython-310-x86_64-linux-gnu.so 
_cffi_backend.cpython-310-x86_64-linux-gnu.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped

@hgy59 I'm now basically done with this PR which took me way more cycles than anticipated. python+boost+libtorrent are a real pain to deal with.

A second pair of eye would be needed in particular for the new framework functionality I've added. This pertains to the addition of new variable called GCC_DEBUG_INFO that when set to 1 will change the optimization flags in order to include debug_info library symbols which in turns help for lower-level gdb debugging.