-
Notifications
You must be signed in to change notification settings - Fork 10.5k
runtime: fix compile failure from use of _Unwind_Backtrace() on FreeBSD 13.0 #61693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: fix compile failure from use of _Unwind_Backtrace() on FreeBSD 13.0 #61693
Conversation
FreeBSD's libunwind situation is complex. It uses LLVM's libunwind library, built as part of FreeBSD's libgcc_s.so. (The latter, despite its name, does not actually come from gcc in modern FreeBSD.) However, it *also* uses libcxxrt (not LLVM's libcxxabi). libcxxrt installs an <unwind.h> originally from <https://github.com/libunwind/libunwind>. That <unwind.h> surrounds its declaration of _Unwind_Backtrace with _GNU_SOURCE guards. Therefore: on FreeBSD, define _GNU_SOURCE so that withCurrentBacktraceImpl() can access _Unwind_Backtrace. For posterity, a (probably partial) list of the various <unwind.h>s (and how they relate to this change): 1. gcc provides one as part of its libgcc (FreeBSD does not use gcc and provides its own libgcc that does not have an <unwind.h>) 2. LLVM's libunwind provides one (but FreeBSD does not install it) 3. <https://github.com/libunwind/libunwind> provides one (FreeBSD has this one, via its libc++, via its libcxxrt) 4. clang provides one (FreeBSD *has* this one, but the header search path for C++ source files prefers number 3)
Note that this is similar to what clang's <unwind.h> does. Incidentally, its presence there is vestigial: it's conditionalized to Darwin-only, but Darwin's system <unwind.h> has never had |
Oh, I just noticed that there is a change in FreeBSD 13.1 (released in May 2022) that removes the offending <unwind.h> from libcxxrt and replace it with the one from LLVM's libunwind. The change is new to 13.1 and not in 13.0, which is where I was testing. I still think this change might be desirable in order to allow building on FreeBSD 13.0, but if not, updating to 13.1 could be a reasonable workaround. |
@swift-ci please smoke test |
// has a header guard. | ||
# define _GNU_SOURCE | ||
# define _SHOULD_UNDEFINE_GNU_SOURCE | ||
# endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How terrible would it be to define _GNU_SOURCE
when building just this source file for FreeBSD? That would impact any other headers included, but should be generally acceptable I imagine. That could then sink this into the build system as:
set_source_files_properties(Errors.cpp PROPERTIES
COMPILE_DEFINITIONS $<$<PLATFORM_ID:FreeBSD>:_GNU_SOURCE>)
For other reasons, I've decided to require FreeBSD 13.1 as the base system for building. Since FreeBSD 13.1 uses the LLVM unwind.h, the problem doesn't exist there, and so this fix isn't needed. Therefore, I'm going to close this PR without merging. |
FreeBSD's libunwind situation is complex. It uses LLVM's libunwind library, built as part of FreeBSD's libgcc_s.so. (The latter, despite its name, does not actually come from gcc in modern FreeBSD.)
However, it also uses libcxxrt (not LLVM's libcxxabi). libcxxrt installs an <unwind.h> originally from https://github.com/libunwind/libunwind. That <unwind.h> surrounds its declaration of _Unwind_Backtrace with _GNU_SOURCE guards.
Therefore: on FreeBSD, define _GNU_SOURCE so that withCurrentBacktraceImpl() can access _Unwind_Backtrace.
For posterity, a (probably partial) list of the various <unwind.h>s (and how they relate to this change):