-
Notifications
You must be signed in to change notification settings - Fork 41
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
Padding in layout of std::string with allocator #718
Comments
The current layout is somewhat inefficient with an allocator: #718
The current layout is somewhat inefficient with an allocator: #718
The current layout is somewhat inefficient with an allocator: CTSRD-CHERI/llvm-project#718
Are there any other similar knobs for C++'s ABI that we should also consider enabling for purecap? It's effectively a new architecture in LLVM and CheriBSD, so it doesn't (yet) need backwards ABI compat, so it would make sense for purecap arches to start with with the current ideal ABI for libc++. |
We could set _LIBCPP_ABI_VERSION=2. However, that is the current unstable ABI which means future libc++ updates could break the ABI. Hopefully they decide to fix version 2 at some point soon... |
Here is the current list of ABI changes in v2:
|
If we do that, do all the headers get installed to /usr/include/c++/v2? If so, that might be a bit more invasive of a change to deal with. |
Looking at libcxx/test/libcxx/strings/basic.string/sizeof.compile.pass.cpp, it turns out that using a std::string with a custom allocator and 32-bit size_type results in padding that cannot be reused by the allocator via __compressed_pair.
The fix would be to store the pointer member before the size_type members in __long, which is what the _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT does. However, we still use the v1 ABI so this is not enabled by default.
Should we enable _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT for purecap on the next breaking ABI change?
The text was updated successfully, but these errors were encountered: