Better watch out! D runs on watchOS!
Joakim via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Mon Jan 4 03:24:04 PST 2016
On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
> Joakim <dlang at joakim.fea.st> 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.
More information about the Digitalmars-d-announce
mailing list