Page MenuHomePhabricator

[libc++] Drop the legacy debug mode symbols by default
ClosedPublic

Authored by ldionne on Jun 8 2022, 3:46 PM.

Details

Summary

Leave the escape hatch in place with a note, but don't include the
debug mode symbols by default since we don't support the debug mode
in the normal library anymore.

This is technically an ABI break for users who were depending on
those debug mode symbols in the dylib, however those users will
already be broken at compile-time because they must have been using
_LIBCPP_DEBUG=2, which is now an error.

Diff Detail

Event Timeline

ldionne created this revision.Jun 8 2022, 3:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 8 2022, 3:46 PM
Herald added a subscriber: mgorny. · View Herald Transcript
ldionne requested review of this revision.Jun 8 2022, 3:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 8 2022, 3:46 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne added a subscriber: Restricted Project.Jun 8 2022, 3:47 PM

Vendors, heads up -- this is an ABI change.

philnik accepted this revision as: philnik.Jun 8 2022, 3:53 PM
philnik added a subscriber: philnik.

I'm kind-of fearing that there are some applications out there that depend on the debug symbols in their release build somehow. I'm not sure if we want to break them, but that's not my call to make, so I'm fine with this.

I'm kind-of fearing that there are some applications out there that depend on the debug symbols in their release build somehow. I'm not sure if we want to break them, but that's not my call to make, so I'm fine with this.

Right -- this is why this is an ABI-breaking change, actually. I know this isn't a problem for Apple because we've never shipped those debug mode symbols, however it could potentially be for other vendors. That's why I'm adding libc++ vendors to the review -- it would be great if they could take a look in their ecosystem and see if applications are depending on those symbols (I know not all vendors have the capability to do that, but some do have at least a partial view of their ecosystems).

The main reason for this patch goes beyond simple cleanup -- the implementation of the debug mode itself is going to change in ways that are ABI breaking as well, so if we keep this around, it would become stale and out-of-sync with the rest of the debug mode. I'm thinking that we can try making this change, and if vendors encounter significant issues (most likely during qualification of LLVM 15), we can easily flip the switch back to ON by default.

@danalbert @dim I think this is worth your input. Can you confirm whether you folks have been shipping symbols like __ZNSt3__111__libcpp_db10__insert_iEPv (std::__1::__libcpp_db::__insert_i(void*)), and whether you are aware of applications using those symbols?

emaste added a subscriber: emaste.Jun 9 2022, 9:21 AM

@danalbert @dim I think this is worth your input. Can you confirm whether you folks have been shipping symbols like __ZNSt3__111__libcpp_db10__insert_iEPv (std::__1::__libcpp_db::__insert_i(void*)), and whether you are aware of applications using those symbols?

Looking on my laptop I see _ZNSt3__111__libcpp_db10__insert_iEPv in /usr/lib/libc++.so.1, but I suspect they've never been used.

Perhaps another thing that will just be solved with a library rename to libc++.so.2 (for the std::pair / ABIv2 issue).

A few minor nits. I'm happy when our vendors are happy.

libcxx/CMakeLists.txt
208

Do we want to mention in which version it will be removed?

libcxx/docs/ReleaseNotes.rst
194

not your change: instead looks out of place.

195

Here too a version number?

ldionne marked 3 inline comments as done.Jun 27 2022, 6:13 AM

@danalbert @dim I think this is worth your input. Can you confirm whether you folks have been shipping symbols like __ZNSt3__111__libcpp_db10__insert_iEPv (std::__1::__libcpp_db::__insert_i(void*)), and whether you are aware of applications using those symbols?

Looking on my laptop I see _ZNSt3__111__libcpp_db10__insert_iEPv in /usr/lib/libc++.so.1, but I suspect they've never been used.

Indeed, my thinking here is that nobody's using these symbols, and if they do, they're already at risk of non-benign ODR violations. In practice, we've seen serious failures trying to use the debug mode in the past, for example in std::string. Hence, I suspect nobody's been using them, but at worst vendors could chime in here if they try to deploy this change and encounter issues. That's why I'm leaving a escape hatch too -- to give vendors to quickly remediate to any issue they might find while deploying this and give them time to reach out here so we can figure out a path forward.

ldionne updated this revision to Diff 440194.Jun 27 2022, 6:14 AM

Rebase and adjust ABI list tests. We don't check for debug mode symbols in the ABI list tests anymore
since there is an intent to leave the debug mode ABI unstable.

ldionne updated this revision to Diff 445007.Fri, Jul 15, 9:02 AM

Adjust more ABI lists

Mordante accepted this revision as: Mordante.Fri, Jul 15, 9:24 AM

I'm happy with the current version. It still would be great to get more vendor feedback,

MaskRay accepted this revision.Fri, Jul 15, 11:25 AM
ldionne updated this revision to Diff 445078.Fri, Jul 15, 11:38 AM

Update more ABI lists

ldionne updated this revision to Diff 445832.Tue, Jul 19, 8:44 AM

Rebase onto main.

ldionne accepted this revision as: Restricted Project.Tue, Jul 19, 2:15 PM
This revision is now accepted and ready to land.Tue, Jul 19, 2:15 PM
This revision was automatically updated to reflect the committed changes.