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