Joakim <dl...@joakim.fea.st> writes: > On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote: >> On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote: >>> That sounds like this issue I ran into with ARM EH: >>> >>> https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075 >>> >>> I was able to work around it by disabling the mentioned llvm >>> optimization pass: >>> >>> https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42 >>> >>> https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133 >> >> Yup, that's exactly it! The approach I took was to leave >> optimization on, removed the casts, and byte load the data into the >> uint vars. If the dwarf data is not guaranteed to be aligned to the >> data type, then I think this is the approach to take. > > Sounds good, submit a PR and let's get it in.
Was planning to get that PR going then got side tracked by a more difficult ARM exeption unwinding bug. It happens in std.random unittest at LDC -O2 or higher. Does this sound familiar Joakim? The bug is a bad stack pointer which blows up when the last unittest returns. This unittest has all the right conditions to generate stack adjustments around some of the function calls that throw exceptions. The exception landing pad does not fixup the stack adjustment, thus a stack leak on each caught exception. The unittest function epilog restores the stack by adding a fixed offset to match the prolog, so the stack pointer stays wrong when the saved registers and return address are popped. Really looks like LLVM is not doing the right thing with landing pads. In the meantime I patched LLVM to generate epilog that always uses frame pointer to restore the stack pointer. WatchOS requires a frame pointer, so this isn't too bad. Now all unittests pass at -O3 for watchOS. I am guessing iOS is not effected since it uses SjLj to restore the stack after an exception is thrown. I'll have to pursue this later. My mind is freed up for the original PR. -- Dan