GrapheneOS
Do not include bits/functexcept.h when building with libc++
This header exists only in GCC's libstdc++. If we are building on a
system using exclusively LLVM's libc++, compilation will fail.
Add an option to the config files to control using libc++. This will
cause this header to not be included if and only if CONFIG_USE_LIBCXX
is true and we are not using GCC.
Doesn't this break the compilation when used with libc++ and -fnot-exceptions?
Doesn't this break the compilation when used with libc++ and
-fnot-exceptions?
It seems I can reproduce a build failure with -fno-exceptions in the CI on the existing workflows. How should this be tested?
The newly added workflow is building successfully now but is currently failing tests, and I can reproduce these on my local machine:
python3 -m unittest discover --start-directory test/
...........................FF..F.....
======================================================================
FAIL: test_uninitialized_free (test_smc.TestSimpleMemoryCorruption)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/concord/Projects/hardened_malloc/test/test_smc.py", line 156, in test_uninitialized_free
self.assertEqual(stderr.decode("utf-8"),
AssertionError: 'fatal allocator error: invalid uninitialized allocator usage\n' != 'fatal allocator error: invalid free\n'
- fatal allocator error: invalid uninitialized allocator usage
+ fatal allocator error: invalid free
======================================================================
FAIL: test_uninitialized_malloc_usable_size (test_smc.TestSimpleMemoryCorruption)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/concord/Projects/hardened_malloc/test/test_smc.py", line 163, in test_uninitialized_malloc_usable_size
self.assertEqual(stderr.decode("utf-8"),
AssertionError: 'fatal allocator error: invalid uninitialized allocator usage\n' != 'fatal allocator error: invalid malloc_usable_size\n'
- fatal allocator error: invalid uninitialized allocator usage
+ fatal allocator error: invalid malloc_usable_size
======================================================================
FAIL: test_uninitialized_realloc (test_smc.TestSimpleMemoryCorruption)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/concord/Projects/hardened_malloc/test/test_smc.py", line 169, in test_uninitialized_realloc
self.assertEqual(stderr.decode("utf-8"),
AssertionError: 'fatal allocator error: invalid uninitialized allocator usage\n' != 'fatal allocator error: invalid realloc\n'
- fatal allocator error: invalid uninitialized allocator usage
? ^^^^^^^^^^^ -- ----------
+ fatal allocator error: invalid realloc
? ^
----------------------------------------------------------------------
Ran 37 tests in 0.116s
FAILED (failures=3)
A first step would be to add a test for -fno-exceptions in the CI as a separate pull-request, then move forward with this one I think.
I might give it a try later this week, but feel free to send one before me :)
Unfortunately I'm kind of at a stand-still with this one. As this PR stands, hardened_malloc will build and run when linked against libc++ but we definitely should have tests enabled in CI for these builds. It looks like for some reason when linked with libc++, the allocator isn't getting properly initialized and I'm really not sure where to go from here as I'm not familiar with memory allocators.
@jvoisin Would be able to assist with this?
I don't think I'll be able to find some free time any time soon unfortunately :/
Done by https://github.com/GrapheneOS/hardened_malloc/commit/462c2c5293b834bcbdde1d3a9389202ae6e809ff but not tested with it.
If you want to make C++ stdlib configuration in the Makefile, it would probably be best to change how CONFIG_CXX_ALLOCATOR is set up. I only used the CXX := $(CC) approach to deal with LTO so that people don't set CC=clang and end up trying to mix clang and g++.