| Re: [hatari-devel] Enabling _FORTIFY_SOURCE for Debug builds? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi Thomas,
On 13.4.2024 22.53, Thomas Huth wrote:
Weird, I'm using 3.27.7 (on Fedora), and for me, it does not add the -O0
after the -g ... but OK, if there are versions that add -O0 automatically,
it's likely better to remove the -D_FORTIFY_SOURCE again. Done now.
Why you moved FORTIFY_SOURCE behind Debug check few months ago:
https://github.com/hatari/hatari/commit/adc8ae2c9d0a28886e8f70f24ebfceb5097e54a0
?
The reason for it being in the options was catching things before
release i.e. before distros package new Hatari release and complain
about things it warns about (some distros enable FORTIFY_SOURCE for
packages, and Mac tooling also enables some similar checks).
=> Wouldn't it have made more sense to invert your Debug check?
Also, debug builds should IMHO not use any optimization. If you try to debug
such programs in gdb, the code jumps around like made and it is almost
impossible to step through functions.
But unlike ~20 years ago, Gdb actually shows the correct place also in
optimized binaries (as ELF format includes nowadays all the info needed
for that).
Hatari without optimization is no fun at all, that's why it's there. And
-O1 should still be fine with debugging, as far as I can tell. I already
considered -Og in the past, too, but I think that might cause problems with
certain compilers, so it's just "-O" for now which should work OK
everywhere.
Large enough portion of the bugs are such that they manifest only when
code is optimized, that I think debugging non-optimized binaries to be
mostly a waste of time. One needs to verify beforehand that bug
manifests also in non-optimized version, whereas debugging optimized
binaries needs just a little practice, and is useful skill to have. It
e.g. shows whether GCC (voluntarily) inlined the functions you thought
it would...
- Eero