Re: libobjc2 updates

[Josh Freeman]

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev