Implement stacktraces in Sys::Drop()/Error()

[VReaperV]

Requires #1719

Adds stacktraces from <stacktrace> to Sys::Drop()/Error(), to help with debugging.

[illwieckz]

Thanks a lot!

[VReaperV]

error: alias declarations are a C++11 extension [-Werror,-Wc++11-extensions]

Seriously? WTF is this garbage?

[VReaperV]

GCC failure is unrelated, and for some reason using -Wno-array-bounds doesn't stop it.

[VReaperV]

I give up trying to fix that piece of shit. Either we NUKE the unsafe vec3 functions or accept the CI not using USE_CPP23 altogether, I don't care which.

[slipher]

I guess we should fix that vector load thing anyway. It could theoretically cause a segfault if the vector is right against a page boundary.

[VReaperV]

Seems not a lot of packages contain libc++_backtrace. Trixie appears to have it in some of the packages. I might check at a later point if it's viable to build it and/or libc++exp for external_deps, but for now I think it's fine to not do so. Probably also need to check which of the 2 libs is present, since it's preferred to use libc++exp, but it might not be available.

[slipher]

I might check at a later point if it's viable to build it and/or libc++exp for external_deps, but for now I think it's fine to not do so.

Something with a C++ interface is probably not viable for external_deps

[VReaperV]

With GCC on Linux I don't have C++23 yet but it the path remapping works with asserts at least. Also I verified the other day that it works on source_location so I'm pretty sure it should work there.

Didn't work for me on GCC13, I still get the full path there.

What platform are you trying it on? Did you try slipher/stacktrace or just the original branch?

I just know from the other project I implemented the path truncating on it should work for MSVC, GCC Linux and Apple Clang but I hadn't attempted Mingw.

Ubuntu 24.04, I was trying the slipher/stacktrace branch.

[slipher]

OK I reproduced the issue and figured out what's missing. The flag we need is -ffile-prefix-map instead of -fmacro-prefix-map. I thought -fmacro-prefix-map was working after checking with source_location::current(), but I guess the distinction here is whether the path is found in debug info (stack trace), or is emitted as part of normal code gen (__FILE__ or source_location::current()). -fmacro-prefix-map would get you short paths for #1742 rather than this one.

-ffile-prefix-map does have a drawback in that it can make GDB more inconvenient in some cases. If you want to use TUI then you have to manually tell it where the source code is.

[VReaperV]

OK I reproduced the issue and figured out what's missing. The flag we need is -ffile-prefix-map instead of -fmacro-prefix-map. I thought -fmacro-prefix-map was working after checking with source_location::current(), but I guess the distinction here is whether the path is found in debug info (stack trace), or is emitted as part of normal code gen (__FILE__ or source_location::current()). -fmacro-prefix-map would get you short paths for #1742 rather than this one.

-ffile-prefix-map does have a drawback in that it can make GDB more inconvenient in some cases. If you want to use TUI then you have to manually tell it where the source code is.

Haven't tried that change on gcc yet, but on msvc I get:

error C1083: Cannot open source file: ';/d1trimfile:"path to unv here"\Unvanquished\daemon\src;/d1trimfile:"path to unv here"\Unvanquished\daemon': No such file or directory

[VReaperV]

There was a missing whitespace, but fixing that didn't change anything. It either complains that half the preceding flag is unknown (/EHsc in my case, with it complaining about /EH;), or, if moved to the beginning of the flags, about the next option after it (/DWIN32). And it tries to compile a source file based on the option name (e. g. compiling source file '/;/DWIN32').

[VReaperV]

Idk where the random /; comes from, but I'm guessing it's some cmake bullshit.

[VReaperV]

Figured out the issue: ${CMAKE_[C/CXX]_FLAGS} had to be in the quoted string.

[VReaperV]

I'll test on GCC later, but MSVC works fine now.

[VReaperV]

Tested on GCC13, it works fine. Also made the log formatting consistent between compilers.

[slipher]

LGTM