We weren't correctly sign-extending the value being compared, which was
resulting in objects not being deallocated. For some reason, this only
appeared on Windows, even though the code looked wrong on all platforms.
When removing a hash entry that was in the cell assigned to its hash, we
would clear the first bit in the second maps. If this entry was a
secondary value with the same hash, then this value became unreachable.
This very rarely showed up for two reasons. First, most of the tables
are insert-only and so we never try to remove things from them. Second,
it requires a particular sequence of inserts. It occasionally caused
weak references to be susceptible to use after free.
This implementation of objc_exception_throw constructs a
_CxxThrowException-compatible ThrowInfo based on the runtime type of the
passed-in exception. Everything pertaining to the exception is allocated
on the stack before the call and destroyed when/if the stack frame is
aborted.
The construction of ThrowInfo, CatchableTypes, and TypeDescriptors, as
well as mangling, is compatible with Clang/LLVM's MicrosoftCXXABI
exception generator.
This ties Objective-C exceptions on Windows to the C++ exception model,
which allows us to support (unboxed) foreign exceptions and C++ catch of
Objective-C types.
objc_exception_rethrow recycles MicrosoftCXXABI's rethrow.
Contributing-author: Jordan Saunders <jmsaunde@microsoft.com>
Contributing-author: Shayne Hiet-Block <shaynehi@microsoft.com>
We were leaving the isa pointer pointing to the deleted class and were
then following its super_class pointer, both of which are potentially
serious. This didn't show up on FreeBSD, because the relevant memory
was always returned to a thread-local pool and the accesses were
immediately afterwards, so it always worked. It broke with malloc
implementations that were more aggressive about checking for
use-after-free.
We were only doing it to get two definitions, which are both mandated by
the spec, so we may as well avoid all of the headaches involved.
Also remove the extern "C" from the runtime.h include while we're here,
as it is no longer needed.
Fixes#69
Coverage checking of the test suite showed that objc_disposeClassPair
wasn't tested at all, which then led to discovering that it didn't
unregister the class.
This cleans up handling of objects that are not reference counted and
makes their interactions with ARC more consistent. We should probably
generalise this somewhat - it currently special cases NSConstantString
and NSGlobalBlock, but it would be nice to have an API for constant
objects.
This cleans up handling of objects that are not reference counted and
makes their interactions with ARC more consistent. We should probably
generalise this somewhat - it currently special cases NSConstantString
and NSGlobalBlock, but it would be nice to have an API for constant
objects.
This was used with an old LLVM pass to perform speculative inlining. It
is no longer maintained and this code hasn't been tested at all for
years or with nontrivial examples ever.
This has no effect most of the time, but if the runtime is built with
llvm-cov support, then this will cause each test to emit a .profraw
file, which can be merged with:
$ llvm-profdata merge -sparse Test/*.profraw -o libobjc.profdata
This can then be used to generate coverage reports from the test suite
and find code paths that are not currently being tested.
Coverage checking of the test suite showed that objc_disposeClassPair
wasn't tested at all, which then led to discovering that it didn't
unregister the class.
This test was accidentally passing sometimes, with the isa pointer being
set using some bit of memory in inter-object padding. This breaks
horribly with an allocator that packs objects densely.
Fix type of `__cxa_allocate_exception` with recent libsupc++.
Recent versions of GNU libsupc++ provide a definition of `__cxa_allocate_exception` that has a `noexcept` qualifier. This is sensible (if allocating an exception throws an exception, then something is badly wrong) but it not what the ABI spec says. We provide our own definition of this, which must match another if provided.
This wouldn't normally be a problem, but recent libstdc++ headers appear to leak libsupc++ headers into the namespace, so we're seeing these definitions even without explicitly including any C++ ABI-related headers.
David Chisnall
Dustin L. Howett
David Chisnall
davidchisnall
Jason Barmparesos