Ahh, I came across this article trying and failing to rebuild glibc in debug mode on Arch Linux, and it would always error out due to _FORTIFY_SOURCE (eeg. <a href="https://bbs.archlinux.org/viewtopic.php?id=245755" rel="nofollow">https://bbs.archlinux.org/viewtopic.php?id=245755</a>). IIRC I tried creating a chroot but ran into the same error (or couldn't make the chroot work, forgot which). In the end I gave up rebuilding glibc in debug mode (since it would've slowed down <i>all</i> my programs). I still don't know what I did wrong; maybe glibc is just incompatible with optimizations off.<p>Nowadays Arch uploads package symbols to debug packages and servers accessible by debuginfod (<a href="https://wiki.archlinux.org/title/Debugging/Getting_traces" rel="nofollow">https://wiki.archlinux.org/title/Debugging/Getting_traces</a>), but I've observed debuginfod <i>greatly</i> slows down gdb and valgrind and strace (so I don't set the DEBUGINFOD_URLS environment variable by default, only when actually debugging).
So _FORTIFY_SOURCE adds checks to functions like memcpy(), but seems to do nothing to help custom code that uses for loops and array indexing.<p>I guess I'll keep using -fsanitize=address (ASan) in my debug builds.
> This promises to significantly widen fortification coverage to include cases where the compiler can see the non-constant expression for object size.<p>Any stats on the coverage increase?
I understand the need for constructions like this, and I understand the limitations you work with when dealing with older languages such as C or C++, but does anyone else think that this is just incredibly hacky?<p>I mean, this is the kind of stuff that needs to be taken care of at the language level. But I guess that's impossible, so we have this instead. Still, progress! I guess.