Few cents about my commits

CocoaTouch: tonns of wrong enum marshalers


Once Issue #373 (Wrong data type of MIDINotificationMessageID enum) was opened it is clear that cocoa-touch had to be revised for enum marshalers case.
This issue wasn’t exposed till #373 and was around for years but anyway it is just metter of time till someone finds another one.

What’s wrong

Marshalers are compilation time annotations that specifies RoboVM compiler the way how to convert native/objc object to java side and back. In case of enums it is usualy specifies size of integer used by enum type in native/objc (e.g. signed/unsigned char/short/int/long).
Using wrong size/sign integer type marshalers leads to data loss (when wrong value read from memory) and potentionaly memory corruption on write attempt.

  • using enum type as member of structure (#373)
  • accessing enum type value by pointer

Why it was in general working

iOS 12.2 bindings, what's new in bro-gen


iOS 12.2

iOS 12.2 has arrived as PR363. It reflects changes apple did. Beside updating API robovm-cocoatouch received following updates:

  • fixed broken structs in AudioToolBox;
  • added IntentsUI framework;
  • added UserNotificationsUI framework;

What’s new in bro-gen

LLVM7-8: vol3 -- its alive. Update#3



Still waiting for official LLVM8 release but it was already tagged.
Meanwhile code was migrate to LLVM8 and commited to dkimitsa/robovm/llvm_80. Following was adapted:

  • bindings;
  • native code;
  • patches.

Code under LLVM8 branch can compile and produce runnable code.
Also both LLVM7/8 has been merged with debugger_local_resolution branch;

Next steps:

  • resurect and run RoboVm tests;
  • evaluate performance and size footprint of LLVM7 produced code;

Previous updates:

RoboVM 2.3.6 released, what's new


What’s new

  • [fix] Xcode project generator: added argument type to IBAction #323
  • [added] forceLinkMethods configuration option to preserve method from aggressive tree shaker, details
  • [fixed] compile dependency declaration bug with gradle 4;
  • [added] putByte/getByte support for Unsafe
  • [updated] cocoa touch bindings up to ios 12.1, new frameworks etc
  • [added] experimental option to enable incremental compilation, thanks @dthomes. #334
  • [fixed] support for vectors which unchainder ARKit, details
  • [fixed] Invalid Swift Support issue when submitting to apple build created using XCode 10.1/10.2;
  • [added] preservePorts option to Sygnals.installSignals API, to supress reporting of handled NPE to Crashlitics, details

Useful tutorials

LLVM7: vol2 -- its alive. Update#2



As per today code from dkimitsa/robovm/llvm_70 is able compile and start application in simulator/device. It gets alive status. What had been done:

  • RoboVm compiler infrastructure was updated to produce llvm 7 compatible IR code;
  • DebugInformationPlugin was reworked to produce llvm7 debug information;
  • Bunch of code was changed as it was broken as per llvm7 vision and produced crashes on asserts inside LLVM.

Next steps:

  • merge with debugger_local_resolution branch;
  • resurect and run RoboVm tests;
  • evaluate performance and size footprint of LLVM7 produced code;
  • migrate to LLVM 8 – yep it has to be released this month.

Previous updates:

Crashlytics: fight for exception handler


This post continues tutorial for proper initialization of crash reporters t. Today it focus around issue 350:Crashlytics: Caught exceptions are being reported as crashes.

Root case

Signals.installSignals() preserves signals handlers and allows RoboVM to handle NPE. But Crashlytics also uses mach exception handler to get crash Apple way. These have priority over signals and this allows Crashlytics to see null pointer exception (EXC_BAD_ACCESS) before RoboVM detects it and report.

The fix

Debugger: improving kotlin support and fixing #220


tutorial: RoboVM and Struct pointers mess


A struct in the C is a composite data type placed under one name in a block of memory, allowing the different variables to be accessed via a single pointer wiki.
The Bro Java to Native Bridge supports structs data type. And there are several scenarios how they are used:

LLVM7: vol1 -- kickoff and Update#1


Experiment with LLVM7 had been started. Current version of LLVM used is 3.6. Version 7 itself will not introduce any significant improvement for RoboVM compiler so far. Goal for this activity is to refresh dependencies code base.
Source code of all changes is stored in separate branch dkimitsa/robovm/llvm_70.


Very brief: LLVM library code compiles but nothing was running yet.

What has been done so far:

  • LLVM and Clang mirror repos are used as source base;
  • CMake build files updated to compile version 7;
  • Swig files for java bindings were cleaned up initially to produce clean results without need of post-work-arounds;
  • LLMV Extra code – set of helpers and wrappers used by RoboVM were updated to work with new LLVM;
  • Swift files for bindings were updated to produce v7 wrappers;
  • RoboVM compiler’s code were updated as LLVM API was changed and lot of functionality was deprecated.

All these changes brought LLVM 7 code into project and now its possible to compile RoboVM compiler code.
Things to do(high level overview):

  • RoboVm has to produce LLVM7 IR code as 3.6 is not compatible anymore;
  • Debugger DWARF IR information is also not compatible with 7.0 and has to be reworked;
  • bugs-bugs-bugs

Fix: Xcode10.1 - Invalid Swift Support



As result of testing rules_apple was wrong and Apple reject such binaries.
In general it would be enough just tp fix issue introduced in PR340 but bitcode strip and SwiftSupport/iphoneos/ will also stay as part of this PR.

Starting from Xcode 10 ARM64E arch has to be stripped from included framworks as this caused Invalid Swift Support at Apple side. There was a fix for it but sadly there was no feedback and another was introduced during the fix. As result investigation continue with Eric Nondahl report and fix is ongoing (not confirmed yet).

To fix this issue PR346 is created and it introduces following changes:

  • fixes issue introduced in PR340: copy of swift libraries in SwiftSupport/ was stripped from ARM64E arch but shell not be touched at all;
  • swift libraries are now being copied into SwiftSupport/iphoneos/ same as XCode does;
  • added code that strips all not used architectures from dynamic binaries (check rules_apple for reference). Probably it is extra as it is enough to remove simulator archs and ARM64E but it is quick win as reduces IPA size. So if it is not breaking anything lets keeping it;
  • added code that strips bitcode from dynamic binaries. Same as Xcode does. Reduces final IPA a lot;
  • as now all extra architectures are being stripped there is no need for stripArchs configuration option that was introduced in PR340. It was removed.

Solution is in progress, please report to gitter channel for any issue found.