Hi David,
Thank you for your work on these fixes!
Cheers,
Josh
On Mar 31, 2019, at 7:58 AM, David Chisnall wrote:
Hello the list,
A kind volunteer gave me access to a BeagleBone Black running
FreeBSD, so I have now been able to test the runtime with ARM
(AArch32) and fixed a few issues:
- [Probably FreeBSD specific], on ARM .init_array initialisers are
run, but .ctors are not, so the compiler needs to use .init_array
for the call into the runtime to register a binary. This is now
fixed in upstream LLVM.
- The ARM objc_msgSend implementation no longer uses text
relocations, so can be mapped read-only in the process. This should
fix it on 32-bit Android. I also have a patch in the related issue
for AArch64 - anyone with a 64-bit ARM system handy, please test it!
- The C++ exception structure used by the runtime did not
incorporate the extra fields that the ARM EH ABI adds. This caused
some state corruption with Objective-C++ exceptions and is now fixed.
- [Possibly FreeBSD specific] the GNU unwinder on ARM appears to not
quite follow the ARM EH ABI spec. It calls the personality function
to install the handler without doing a phase-1 search. This is now
worked around in the runtime.
The runtime (master branch, due to be released as 2.0) now passes
all of the tests on ARM, except for a small number that are not
architecture specific, but run out of memory on the test platform.
I've also fixed a few other bugs:
- A memory leak in @synchronized that Fred pointed out. We only
leaked a few bytes for every object used with @synchronized, but in
a loop it was easy for this to be a problem. I had not seen this
issue because I avoid using @synchronized entirely. It is a
horrible feature in Objective-C and using __attribute__((cleanup))
for the unlock in C (or RAII in C++) lets you accomplish the same
thing with less inefficiency. The feature wouldn't be such a
problem if it were defined to send -lock / -unlock messages to the
object, but requiring the runtime to maintain a lock for each object
is awkward.
- There was an issue with static builds where the Protocol class was
not being linked unless explicitly used outside of the runtime.
This, in turn, broke the runtime's detection that the __objc_load
function was being called for the runtime itself, which broke the
ABI mismatch detection. This is now fixed and static linking
probably works again.
- The compiler occasionally emits negative offsets for ivars in the
non-fragile ABI when, in the fragile ABI version of the class they
would be within the space allocated by the superclass. The runtime
was not handling this correctly and so we were ending up with
nonsense (sometimes negative) offsets for classes that contained
BOOLs as their first fields if the compiler could see the layout of
the superclass and it ended with something less than the size of a
pointer. This triggered some very odd behaviour in -gui with some
non-default defaults values set (and almost certainly broke GSMime,
though I didn't see any reports of that).
I have now tested and committed Dustin Howett's patches to clang for
improving the Windows support. It is now possible to use upstream
clang (master branch, not any releases yet) to build WinObjC and
have all of the tests pass (with some not-yet-merged patches to
WinObjC, including updating their copy of libobjc2 to a recent trunk).
On Windows, we now have fully interoperable exceptions: The 2.0 ABI
uses SEH-compatible exceptions and Objective-C++ code compiled with
clang-cl will use the same ABI as the visual studio compiler for C++.
I have now moved the CI over to using Azure Pipelines, so there are
CI builds on Windows and Ubuntu. This should help avoiding
regressions on Windows.
If you see any other issues, please report them on GitHub!
David
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev