The debug mode goes back to the early days of libc++; unfortunately, several important issues were discovered with its original design along the way because of which further development was effectively abandoned. The debug mode is currently in a legacy state and not actively maintained; some vendors, including Apple, never shipped it.
Most of the issues with the design stem from the decision to have a global database for storing debug information:
All accesses to the database require taking a global lock, adding a significant performance penalty;
The debug mode is not usable in a constexpr context;
The initial goal of the debug mode was to be ABI compatible with the normal library. Unfortunately, this doesn’t work since the state of the global database needs to be updated consistently throughout the whole application, which means that it is effectively ABI affecting. This was discovered when we noticed actual runtime issues while mixing components built with different settings for the debug mode.
For these reasons, the legacy debug mode has been a maintenance burden for a while, but this became especially noticeable due to the recent work on hardening in libc++. There is a fair amount of conceptual overlap between the new hardening modes and the legacy debug mode, and having the two coexist ends up being confusing, particularly for users of the library trying to figure out which settings need to be turned on to enable the hardening mode. We propose to simply remove the legacy debug mode from libc++, to be replaced by the new hardening modes (including the new debug mode).
As for the timeline, we would:
Switch the default for enabling debug mode support in the shared library from ON to OFF in LLVM 17.
Have a release note and a deprecation warning for vendors and users when the debug mode is enabled in LLVM 17.
Remove support for the legacy debug mode in LLVM 18.
I support this, however since this is a potentially breaking change (see below), I think it would be nice to get the attention of a few other vendors on this.
This is a breaking change because we’d be removing the symbols that implement the global database. Anyone relying on those right now would get linker errors when the removal is complete. However, as it is explained above, this legacy debug mode is effectively already broken so I would argue that anyone relying on it must not be relying on it in production.
We don’t think there are many users relying on it because it’s already broken, and we’d like to be able to reuse some of the names associated to the debug mode sooner than in ~1 year.
I think it makes complete sense to remove the legacy debug mode. So far as I’m aware, Google only ever tried to use _LIBCPP_DEBUG level 1, and that has been completely replaced with the hardening mode, which has been great.
Let me take a moment to thank the libc++ community for that feature! Chrome is very interested in minimizing C++ library UB, and this was a major improvement.
I think you would be justified in removing the old debug mode sooner than later. Maybe you could make some backwards compatibility compromises, like providing stubs for the symbols exposed in past shared library versions. There is a large space of reasonable solutions.
I think this allows us to significantly speed up the timeline and remove the legacy debug mode for the upcoming LLVM 17 release. This is great for hardening work because it saves us from distinguishing between the “legacy” and the “new” debug mode and just reuse the obvious name.
Please let us know if there are any objections to removing the legacy debug mode in the upcoming release. The fact that there were no complaints about the previous changes seems to indicate lack of usage.