On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
Joakim <[email protected]> writes:
On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
[...]
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?
Yep, except tests were failing in three unittest blocks with -O1
too, but I never looked into exactly why:
https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3139
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.
Could be the same issue for me, not sure. If you put your fix
online, I can try it and see.
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.
That one is much simpler, let's get it in.
