llvm-project.git/libcxxabi/src/fallback_malloc.cpp, branch users/aokblast/readelf/pxnum_support Unnamed repository; edit this file 'description' to name the repository. [libc++][RFC] Always define internal feature test macros (#89178) 2024-10-12T07:49:52+00:00 Nikolas Klauser nikolasklauser@berlin.de 2024-10-12T07:49:52+00:00 ba87515fea90b5d55836a8e3be63a7e683ce299d Currently, the library-internal feature test macros are only defined if the feature is not available, and always have the prefix `_LIBCPP_HAS_NO_`. This patch changes that, so that they are always defined and have the prefix `_LIBCPP_HAS_` instead. This changes the canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means that using an undefined macro (e.g. due to a missing include) is diagnosed now. While this is rather unlikely currently, a similar change in `<__configuration/availability.h>` caught a few bugs. This also improves readability, since it removes the double-negation of `#ifndef _LIBCPP_HAS_NO_FEATURE`. The current patch only touches the macros defined in `<__config>`. If people are happy with this approach, I'll make a follow-up PR to also change the macros defined in `<__config_site>`. 
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.

The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
 [libc++abi] Revert temporary workaround to unblock Chrome 2024-02-05T17:19:15+00:00 Louis Dionne ldionne.2@gmail.com 2024-02-05T17:18:52+00:00 c5f68a711c62aa1748c03215d95ad9b8c7dff9dd This reverts commit 372f7dd48f016, which is not needed by Chrome anymore. 
This reverts commit 372f7dd48f016, which is not needed by Chrome anymore.
[libc++abi] Add temporary workaround to unblock Chrome 2024-01-31T17:53:33+00:00 Louis Dionne ldionne.2@gmail.com 2024-01-31T17:53:32+00:00 372f7dd48f0165c6a7cdc819516132c617ef6f45 Chrome rolls libc++ and libc++abi as separate projects. As a result, they may not always be updated in lockstep, and this can lead to build failures when mixing libc++ that doesn't have <__thread/support.h> with libc++abi that requires it. This patch adds a workaround to make libc++abi work with both versions. While Chrome's setup is not supported, this workaround will allow them to go back to green and do the required work needed to roll libc++ and libc++abi in lockstep. This workaround will be short-lived -- I have a reminder to go back and remove it by EOW. 
Chrome rolls libc++ and libc++abi as separate projects. As a result, they
may not always be updated in lockstep, and this can lead to build failures
when mixing libc++ that doesn't have <__thread/support.h> with libc++abi
that requires it.

This patch adds a workaround to make libc++abi work with both versions.
While Chrome's setup is not supported, this workaround will allow them
to go back to green and do the required work needed to roll libc++ and
libc++abi in lockstep. This workaround will be short-lived -- I have a
reminder to go back and remove it by EOW.
[libc++] Split the monolithic __threading_support header (#79654) 2024-01-30T13:35:15+00:00 Louis Dionne ldionne.2@gmail.com 2024-01-30T13:35:15+00:00 7162fd750ee5f786f3b9b7a7b26b72ee36ce772e The <__threading_support> header is a huge beast and it's really difficult to navigate. I find myself struggling to find what I want every time I have to open it, and I've been considering splitting it up for years for that reason. This patch aims not to contain any functional change. The various implementations of the threading base are simply moved to separate headers and then the individual headers are simplified in mechanical ways. For example, we used to have redundant declarations of all the functions at the top of `__threading_support`, and those are removed since they are not needed anymore. The various #ifdefs are also simplified and removed when they become unnecessary. Finally, this patch adds documentation for the API we expect from any threading implementation. 
The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I want
every time I have to open it, and I've been considering splitting it up
for years for that reason.

This patch aims not to contain any functional change. The various
implementations of the threading base are simply moved to separate
headers and then the individual headers are simplified in mechanical
ways. For example, we used to have redundant declarations of all the
functions at the top of `__threading_support`, and those are removed
since they are not needed anymore. The various #ifdefs are also
simplified and removed when they become unnecessary.

Finally, this patch adds documentation for the API we expect from any
threading implementation.
 [libc++abi] Avoid raw calls to assert() in libc++abi (#71121) 2023-11-23T23:21:43+00:00 Louis Dionne ldionne.2@gmail.com 2023-11-23T23:21:43+00:00 c4779ea8e709a7bce7288988fabf1ba50e9c9477 The runtimes now have a principled way of doing assertions in relation to hardening, so we should use that instead of raw calls to assert() inside libc++abi. This patch aims to maintain the behavior of the demangler code when it is used from within LLVM by introducing a simple DEMANGLE_ASSERT(...) macro that is then defined to the appropriate assertion mechanism. 
The runtimes now have a principled way of doing assertions in relation
to hardening, so we should use that instead of raw calls to assert()
inside libc++abi. This patch aims to maintain the behavior of the
demangler code when it is used from within LLVM by introducing a simple
DEMANGLE_ASSERT(...) macro that is then defined to the appropriate
assertion mechanism.
 [libc++] Move the definition of aligned allocation helpers outside of <new> 2023-01-26T19:41:13+00:00 Louis Dionne ldionne.2@gmail.com 2022-12-02T21:45:49+00:00 36080434a8858c33f2af2382be748caed131385f They are not needed in <new> -- in fact they are only needed in .cpp files. Getting those out of the way makes the headers smaller and also makes it easier to use the library on platforms where aligned allocation is not available. Differential Revision: https://reviews.llvm.org/D139231 
They are not needed in <new> -- in fact they are only needed in .cpp files.
Getting those out of the way makes the headers smaller and also makes it
easier to use the library on platforms where aligned allocation is not
available.

Differential Revision: https://reviews.llvm.org/D139231
Revert "[libcxxabi] Always use thread_local for cxa_exception_storage" 2022-11-24T13:32:10+00:00 Louis Dionne ldionne.2@gmail.com 2022-11-24T13:32:10+00:00 bc91104e85b7a233a8966998f387b2222f350f6e This reverts commit 8271aa5335668a1dc62168a4e90b4554bd3a0ca7 since it broke some downstream builds. See https://reviews.llvm.org/D138461 for details. 
This reverts commit 8271aa5335668a1dc62168a4e90b4554bd3a0ca7 since it
broke some downstream builds. See https://reviews.llvm.org/D138461 for
details.
[libcxxabi] Always use thread_local for cxa_exception_storage 2022-11-22T20:22:06+00:00 Shoaib Meenai smeenai@fb.com 2022-11-21T23:59:42+00:00 8271aa5335668a1dc62168a4e90b4554bd3a0ca7 This was previously guarded by HAS_THREAD_LOCAL, which was never set by CMake and had to be specified manually. Android has been setting this to solve https://github.com/android/ndk/issues/1200 [1], but every compiler and platform libc++abi supports should have thread_local by now, so we can just get rid of the fallback implementation and simplify things significantly (including removing the now unused fallback calloc). [1] https://android-review.googlesource.com/c/toolchain/llvm-project/+/1285596 Reviewed By: #libc_abi, MaskRay, ldionne Differential Revision: https://reviews.llvm.org/D138461 
This was previously guarded by HAS_THREAD_LOCAL, which was never set by
CMake and had to be specified manually. Android has been setting this to
solve https://github.com/android/ndk/issues/1200 [1], but every compiler
and platform libc++abi supports should have thread_local by now, so we
can just get rid of the fallback implementation and simplify things
significantly (including removing the now unused fallback calloc).

[1] https://android-review.googlesource.com/c/toolchain/llvm-project/+/1285596

Reviewed By: #libc_abi, MaskRay, ldionne

Differential Revision: https://reviews.llvm.org/D138461
[libcxxabi] Fix alignment of pointers returned by fallback_malloc 2022-08-19T14:07:57+00:00 Simon Tatham simon.tatham@arm.com 2022-08-19T14:07:55+00:00 a771a91dcbe637bc545da510fe5a9a671ab5e977 This aligns the ``heap[]`` array in ``fallback_malloc.cpp`` to ensure that it can be safely cast to ``heap_node*``, and also adjusts the allocation algorithm to ensure that every allocated block has the alignment requested by ``__attribute__((aligned))``, by putting the block's ``heap_node`` header 4 bytes before an aligned address. Patch originally by Eric Fiselier: this is an updated version of D12669, which was never landed. Reviewed By: ldionne, #libc_abi Differential Revision: https://reviews.llvm.org/D129842 
This aligns the ``heap[]`` array in ``fallback_malloc.cpp`` to ensure
that it can be safely cast to ``heap_node*``, and also adjusts the
allocation algorithm to ensure that every allocated block has the
alignment requested by ``__attribute__((aligned))``, by putting the
block's ``heap_node`` header 4 bytes before an aligned address.

Patch originally by Eric Fiselier: this is an updated version of
D12669, which was never landed.

Reviewed By: ldionne, #libc_abi

Differential Revision: https://reviews.llvm.org/D129842
[libc++] Revert "Protect users from relying on detail headers" & related changes 2022-03-01T13:20:24+00:00 Louis Dionne ldionne.2@gmail.com 2022-02-28T21:37:25+00:00 368faacac7525e538fa6680aea74e19a75e3458d This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9, which were related to the original commit). As landed, 5aaefa51 had unintended consequences on some downstream bots and didn't have proper coverage upstream due to a few subtle things. Implementing this is something we should do in libc++, however we'll first need to address a few issues listed in https://reviews.llvm.org/D106124#3349710. Differential Revision: https://reviews.llvm.org/D120683 
This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.

Differential Revision: https://reviews.llvm.org/D120683