[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libobjc2 updates
From: |
Fred Kiefer |
Subject: |
Re: libobjc2 updates |
Date: |
Sun, 31 Mar 2019 15:54:16 +0200 |
Very impressive list of improvements. Thank you very much David!
> Am 31.03.2019 um 13:58 schrieb David Chisnall <address@hidden>:
>
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev