Re: libobjc2 updates

[Fred Kiefer]

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