Android/ARM: fixing exception-handling

Joakim via digitalmars-d-ldc digitalmars-d-ldc at puremagic.com
Wed Jul 8 09:14:42 PDT 2015


On Wednesday, 17 June 2015 at 07:32:35 UTC, Joakim wrote:
> I hadn't bothered looking at how your iOS branch dealt with 
> exceptions, since you had said a while back that it uses 
> setjmp/longjmp exceptions, but I'll take a look now and see if 
> there's anything helpful.

Took a look, don't think it's relevant to DWARF exceptions.

> I'll take a look.  Right now, the only change I made to 
> gen/abi.cpp is to use the C calling convention everywhere.

It appears that the only change you made is to turn off passing 
structs by value?

https://github.com/smolt/ldc/blob/ios/gen/abi-ios.cpp#L53

The fast C calling convention works for you?  It always caused 
problems for me on ARM, including causing a segfault in llvm when 
compiling, the last time I tried it.

I spent some time looking into the ARM EH issues and it appears 
that disabling inlining fixes a lot of it:

--- a/gen/optimizer.cpp
+++ b/gen/optimizer.cpp
@@ -163,8 +163,8 @@ static unsigned sizeLevel() {

  // Determines whether or not to run the normal, full inlining 
pass.
  bool willInline() {
-    return enableInlining == cl::BOU_TRUE ||
-        (enableInlining == cl::BOU_UNSET && optLevel() > 1);
+    return enableInlining == cl::BOU_TRUE;// ||
+        //(enableInlining == cl::BOU_UNSET && optLevel() > 1);
  }

  bool isOptimizationEnabled() {

I also get proper backtraces in gdb much more often after turning 
off inlining, not to mention actual error output on the 
command-line as opposed to segfaults.  I'm guessing something is 
screwed up in the generation or handling of DWARF exception data 
by function inlining.  Almost all of druntime now passes tests on 
Android/ARM, with the exception of some codegen issues in 
core.time.

For a comparison, running the phobos tests with logging turned on 
in the ldc/eh.d code showed that only about 67 exceptions were 
thrown with -O2/-O3 -release and inlining turned on.  With 
inlining turned off, it jumps up to 658 exceptions, an order of 
magnitude more, because many more tests are run once EH starts 
working.  A couple exceptions might still be uncaught and need to 
be fixed, but it appears that EH is not the bottleneck anymore, 
it's codegen and other ARM issues.

David, Kai, or whoever else runs tests on linux/Android/ARM, can 
you turn inlining off and verify the same results on your ARM 
hardware?


More information about the digitalmars-d-ldc mailing list