Very impressive list of improvements. Thank you very much David! > Am 31.03.2019 um 13:58 schrieb David Chisnall <gnus...@theravensnest.org>: > > 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
