This change is effectively a no-op (it's impossible to throw an
exception through these trampolines, because they tail call the real
block), but it does prevent the linker from complaining that we're
linking SEH-aware and SEH-unaware code.
On 32-bit Windows, malloc doesn't give us memory with sufficiently
strong alignment for AVX vectors.
Note that Windows also has a family of allocators that provide guarantee
exact misalignment. Using these would simplify the ivar layout logic
slightly, because we wouldn't need to account for the refcount pointer.
It's not clear that it's actually worth doing though, because that logic
already exists.
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.
David Chisnall
Dustin L. Howett
David Chisnall