Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ARM] AOT compiled code with LLVM causes random crashes since Mono 5.16 (was: "Timespan error with last version") #11095

Closed
JTrotta opened this issue Oct 11, 2018 · 45 comments

Comments

@JTrotta
Copy link

@JTrotta JTrotta commented Oct 11, 2018

Steps to Reproduce

  1. create a console application with on line:
    static void Main(string[] args)
    {
    TimeSpan DefaultFlushTimeout = TimeSpan.FromSeconds(15);
    Console.Read();
    }

  2. compile and execute on Linux

  3. crash

Current Behavior

crash

Expected Behavior

working

On which platforms did you notice this

[ ] macOS
[ x] Linux raspberrypi 4.14.70-v7+ #1144 SMP Tue Sep 18 17:34:46 BST 2018 armv7l GNU/Linux
[ ] Windows

Version Used:
Mono JIT compiler version 5.16.0.179 (tarball Thu Oct 4 12:22:11 UTC 2018)

Stacktrace

Unhandled Exception:
System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0x74a03bb8 + 0x0010c> in <c3c5f4bb011a4af8b925b0d39ee12396>:0
  at System.TimeSpan.FromSeconds (System.Double value) <0x74a03e88 + 0x0001b> in <c3c5f4bb011a4af8b925b0d39ee12396>:0
  at ConsoleApp1.Program.Main (System.String[] args) [0x00001] in <49d5660f8e7d40cdb5d5396ccc0c501c>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0x74a03bb8 + 0x0010c> in <c3c5f4bb011a4af8b925b0d39ee12396>:0
  at System.TimeSpan.FromSeconds (System.Double value) <0x74a03e88 + 0x0001b> in <c3c5f4bb011a4af8b925b0d39ee12396>:0
  at ConsoleApp1.Program.Main (System.String[] args) [0x00001] in <49d5660f8e7d40cdb5d5396ccc0c501c>:0

EDIT: WORKAROUND

See suggested workaround #11095 (comment)

@Toxaris-NL

This comment has been minimized.

Copy link

@Toxaris-NL Toxaris-NL commented Oct 14, 2018

As quite a lot of programs are using this functionality, this is a serious issue.

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 17, 2018

This is critical. Duplicati backup stopped working on my Raspberry Pi. I tracked down the problem to TimeSpan.FromMilliseconds(Int32.MaxValue-1) which is used in the Regex class.

I think the problem (OverflowException) occurs here in the file mono/mcs/class/referencesource/mscorlib/system/timespan.cs:

private static TimeSpan Interval(double value, int scale) {
    if (Double.IsNaN(value))
        throw new ArgumentException(Environment.GetResourceString("Arg_CannotBeNaN"));
    Contract.EndContractBlock();
    double tmp = value * scale;
    double millis = tmp + (value >= 0? 0.5: -0.5);
    if ((millis > Int64.MaxValue / TicksPerMillisecond) || (millis < Int64.MinValue / TicksPerMillisecond))
        throw new OverflowException(Environment.GetResourceString("Overflow_TimeSpanTooLong"));
    return new TimeSpan((long)millis * TicksPerMillisecond);
}

The code seems correct and didn't change recently. So I am not sure what exactly happens.
Another thing I noticed is, that the Exception only happens sometimes if I execute the same program again and again, see:

pi@raspberrypi:~ $ mono Main.exe
922337203685477
pi@raspberrypi:~ $ mono Main.exe
922337203685477

Unhandled Exception:
System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0x74a03bc0 + 0x0010c> in <3833a6edf2074b959d3dab898627f0ac>:0
  at System.TimeSpan.FromMilliseconds (System.Double value) <0x74a03cfc + 0x0001b> in <3833a6edf2074b959d3dab898627f0ac>:0
  at JH.Prog.Main () [0x00010] in <00c1beb12fc34cbd912b5e0dfce5bcbb>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0x74a03bc0 + 0x0010c> in <3833a6edf2074b959d3dab898627f0ac>:0
  at System.TimeSpan.FromMilliseconds (System.Double value) <0x74a03cfc + 0x0001b> in <3833a6edf2074b959d3dab898627f0ac>:0
  at JH.Prog.Main () [0x00010] in <00c1beb12fc34cbd912b5e0dfce5bcbb>:0
pi@raspberrypi:~ $ mono Main.exe
922337203685477

Unhandled Exception:
System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0x74a03bc0 + 0x0010c> in <3833a6edf2074b959d3dab898627f0ac>:0
  at System.TimeSpan.FromMilliseconds (System.Double value) <0x74a03cfc + 0x0001b> in <3833a6edf2074b959d3dab898627f0ac>:0
  at JH.Prog.Main () [0x00010] in <00c1beb12fc34cbd912b5e0dfce5bcbb>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0x74a03bc0 + 0x0010c> in <3833a6edf2074b959d3dab898627f0ac>:0
  at System.TimeSpan.FromMilliseconds (System.Double value) <0x74a03cfc + 0x0001b> in <3833a6edf2074b959d3dab898627f0ac>:0

... Also I fail trying to analyze mono with valgrind.
Hope this helps, any ideas?

@alexischr alexischr added this to Bugs Pool in Bugs Week via automation Oct 17, 2018
@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 18, 2018

If I compile the program in Linux (Raspberry) and execute it in Windows or Linux (x86) it does not fail.
Therefore I assume it is a problem with the mono runtime on raspberry pi and not a compiler issue.

Also running "mono --interpreter Main.exe" works without a problem.

@EgorBo

This comment has been minimized.

Copy link
Member

@EgorBo EgorBo commented Oct 23, 2018

@timmi-on-rails is it ARM specific? Can't reproduce it on Ubuntu 18 x64 with mono 5.16
Also what is the 922337203685477 value in your output:

pi@raspberrypi:~ $ mono Main.exe
922337203685477
@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 23, 2018

@timmi-on-rails did you run mono --interpreter Main.exe on the Raspberry Pi? Could you post the output of mono -v -v -v --trace Main.exe to gist.github.com? That would be very helpful.

My guess: Since it works in the interpreter, and Raspberry Pi doesn't do hardware floating point, it could be a problem with "softfloat" in our ARM JIT backend

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 23, 2018

@EgorBo, yes it seems ARM specific. I cannot reproduce it on Linux x86 either.
The output was just some multiplication of Timespan.TicksPerMillisecond times some large number.
It is not relevant. Sorry for not posting a clear source code example. I will do so very soon.

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 23, 2018

@lewurm Yes I did run mono --interpreter Main.exe on the Raspberry Pi for atleast 100 times and no problem occured. I am not sure it is soft float, because I am running Rasbian 9 (debian stretch mod) and the architecture is armhf (hf = hard float). Or is that something different? It is a Raspberry Pi 2.

After the problem occured I had to roll back mono to 5.14 on my Raspberry Pi to get Duplicati working again. Now I wanted to reproduce the problem on a fresh install (separate SD card) with latest mono 5.16 and I have trouble reproducing it again. I upgraded the mono version on my original server (SD card) again and couldn't reproduce it.

Maybe there is already a patch added to raspbian since I tryed last week?
I am not sure how I can figure that out...
Or maybe this is just an issue when updating from 5.14 to 5.16 with apt upgrade, maybe some precompile step is left out... I haven't tested that, because this time I removed the old version and installed the new instead of upgrading.
I could try that again. Can anybody check if there has been a debian/raspbian patch?
@JTrotta Do you use Raspbian?

@JTrotta

This comment has been minimized.

Copy link
Author

@JTrotta JTrotta commented Oct 24, 2018

@timmi-on-rails Yes: Linux raspberrypi 4.14.70-v7+ #1144 SMP Tue Sep 18 17:34:46 BST 2018 armv7l GNU/Linux

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 24, 2018

@JTrotta Can you please remove mono completely and reinstall the latest version 5.16.0.179 again and check if the problem still exists? That would be very helpful.

Currently I assume, that something goes wrong during the apt upgrade command.
I will try to reproduce the upgrade procedure tonight. I will install 5.14.x.x snapshot and upgrade to 5.16.0.179 and we will see what happens.

@JTrotta

This comment has been minimized.

Copy link
Author

@JTrotta JTrotta commented Oct 24, 2018

@timmi-on-rails Of course! Will do today, and let you know in a while.

@JTrotta

This comment has been minimized.

Copy link
Author

@JTrotta JTrotta commented Oct 24, 2018

I can confirm that an installation from scratch works, on Linux raspberrypi 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux.
So, as supposed, the problem is related to scripts update

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 24, 2018

@JTrotta Thank you for trying out so fast. I am still trying to reproduce the malicious upgrade.
Anyone into upgrade scripts business here? :-)

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 24, 2018

So, I can reproduce the problem.
I removed mono completely. Then I installed mono from

deb https://download.mono-project.com/repo/debian stretch/snapshots/5.14 main

and then I changed to the latest repo and ran apt upgrade

deb https://download.mono-project.com/repo/debian stretch main

This way the error is reproducible. Upgrade from 5.14.0.177 to 5.16.0.179.

@lewurm Here the gist of mono -v -v -v --trace Main.exe, although this may be not so important since it seems an apt upgrade issue.
gist: https://gist.githubusercontent.com/timmi-on-rails/6fa644ee16710ce60a148fa08776072b/raw/5ae920c634fc0ff72c9a2cc67edd24b1d5dd9c4d/mono.log

Here is the source code:

using System;

namespace Test
{
  class Program
  {
    public static void Main()
    {
      var ts = TimeSpan.FromMilliseconds(1);
    }
  }
}

So, who can help fix this?

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 24, 2018

@timmi-on-rails what's the output of mono --version on the failing installation? could you also try if your example works when you run mono -O=-aot Main.exe?

Still guessing here, but it could be related to the BCL being AOT compiled during package install with LLVM. @directhex when did we start to ship an LLVM enabled build, that also does AOT compilation of the BCL?

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 25, 2018

I can reproduce on armhf. The BCL is AOT compiled with LLVM:

$ /usr/bin/mono --aot=try-llvm,temp-path=/tmp/monoaot.2Uv5HA3GF,outfile=/usr/lib/mono/aot-cache/arm/mscorlib.dll.so -O=all /usr/lib/mono/4.5/mscorlib.dll
$ objdump -d /usr/lib/mono/aot-cache/arm/mscorlib.dll.so | grep -i -A 90 'interval_double_int>:'
0019bb40 <System_TimeSpan_Interval_double_int>:
  19bb40:       e92d4830        push    {r4, r5, fp, lr}
  19bb44:       e24dd018        sub     sp, sp, #24
  19bb48:       ec432b11        vmov    d1, r2, r3
  19bb4c:       e1a04000        mov     r4, r0
  19bb50:       e3a026ff        mov     r2, #267386880  ; 0xff00000
  19bb54:       e3a03000        mov     r3, #0
  19bb58:       ed8d1b04        vstr    d1, [sp, #16]
  19bb5c:       e3822207        orr     r2, r2, #1879048192     ; 0x70000000
  19bb60:       e59d1014        ldr     r1, [sp, #20]
  19bb64:       e59d0010        ldr     r0, [sp, #16]
  19bb68:       e3c11102        bic     r1, r1, #-2147483648    ; 0x80000000
  19bb6c:       e1510002        cmp     r1, r2
  19bb70:       83a03001        movhi   r3, #1
  19bb74:       e3500000        cmp     r0, #0
  19bb78:       13a00001        movne   r0, #1
  19bb7c:       e1510002        cmp     r1, r2
  19bb80:       11a00003        movne   r0, r3
  19bb84:       e3500000        cmp     r0, #0
  19bb88:       1a000023        bne     19bc1c <System_TimeSpan_Interval_double_int+0xdc>
  19bb8c:       eeb51bc0        vcmpe.f64       d1, #0.0
  19bb90:       e59d0028        ldr     r0, [sp, #40]   ; 0x28
  19bb94:       e28f10b4        add     r1, pc, #180    ; 0xb4
  19bb98:       ed9f3b30        vldr    d3, [pc, #192]  ; 19bc60 <System_TimeSpan_Interval_double_int+0x120>
  19bb9c:       eef1fa10        vmrs    APSR_nzcv, fpscr
  19bba0:       b2811008        addlt   r1, r1, #8
  19bba4:       ed910b00        vldr    d0, [r1]
  19bba8:       ee020a10        vmov    s4, r0
  19bbac:       eeb82bc2        vcvt.f64.s32    d2, s4
  19bbb0:       ee020b01        vmla.f64        d0, d2, d1
  19bbb4:       eeb40bc3        vcmpe.f64       d0, d3
  19bbb8:       eef1fa10        vmrs    APSR_nzcv, fpscr
  19bbbc:       ca00001c        bgt     19bc34 <System_TimeSpan_Interval_double_int+0xf4>
  19bbc0:       ed9f1b28        vldr    d1, [pc, #160]  ; 19bc68 <System_TimeSpan_Interval_double_int+0x128>
  19bbc4:       eeb40bc1        vcmpe.f64       d0, d1
  19bbc8:       eef1fa10        vmrs    APSR_nzcv, fpscr
  19bbcc:       4a000018        bmi     19bc34 <System_TimeSpan_Interval_double_int+0xf4>
  19bbd0:       eb130bfe        bl      65ebd0 <plt__jit_icall___emul_fconv_to_i8>  19bbd4:       e3a02e71        mov     r2, #1808       ; 0x710
  19bbd8:       e3a03000        mov     r3, #0  19bbdc:       e3a05000        mov     r5, #0
  19bbe0:       e3822a02        orr     r2, r2, #8192   ; 0x2000
  19bbe4:       eb12ed91        bl      657230 <plt__jit_icall___emul_lmul>  19bbe8:       e58d5004        str     r5, [sp, #4]
  19bbec:       e58d5000        str     r5, [sp]
  19bbf0:       e58d1004        str     r1, [sp, #4]  19bbf4:       e58d0000        str     r0, [sp]
  19bbf8:       e58d100c        str     r1, [sp, #12]  19bbfc:       e58d0008        str     r0, [sp, #8]
  19bc00:       e59d0008        ldr     r0, [sp, #8]
  19bc04:       e5840000        str     r0, [r4]
  19bc08:       e59d000c        ldr     r0, [sp, #12]
  19bc0c:       e5840004        str     r0, [r4, #4]
  19bc10:       e28dd018        add     sp, sp, #24
  19bc14:       e8bd4830        pop     {r4, r5, fp, lr}
  19bc18:       e1a0f00e        mov     pc, lr
  19bc1c:       e59f0050        ldr     r0, [pc, #80]   ; 19bc74 <System_TimeSpan_Interval_double_int+0x134>
  19bc20:       eb12de1a        bl      653490 <plt__jit_icall_mono_helper_ldstr_mscorlib>
  19bc24:       e1a01000        mov     r1, r0
  19bc28:       e59f0048        ldr     r0, [pc, #72]   ; 19bc78 <System_TimeSpan_Interval_double_int+0x138>  19bc2c:       eb12de6b        bl      6535e0 <plt__jit_icall_mono_create_corlib_exception_1>
  19bc30:       eb12de1e        bl      6534b0 <plt__jit_icall_mono_arch_throw_exception>
  19bc34:       e3a00032        mov     r0, #50 ; 0x32
  19bc38:       e3800801        orr     r0, r0, #65536  ; 0x10000
  19bc3c:       eb12de13        bl      653490 <plt__jit_icall_mono_helper_ldstr_mscorlib>
  19bc40:       e1a01000        mov     r1, r0
  19bc44:       e59f0024        ldr     r0, [pc, #36]   ; 19bc70 <System_TimeSpan_Interval_double_int+0x130>
  19bc48:       eb12de64        bl      6535e0 <plt__jit_icall_mono_create_corlib_exception_1>  19bc4c:       eb12de17        bl      6534b0 <plt__jit_icall_mono_arch_throw_exception>  19bc50:       00000000        .word   0x00000000  19bc54:       3fe00000        .word   0x3fe00000
  19bc58:       00000000        .word   0x00000000  19bc5c:       bfe00000        .word   0xbfe00000
  19bc60:       eb1c4328        .word   0xeb1c4328  19bc64:       430a36e2        .word   0x430a36e2
  19bc68:       eb1c4328        .word   0xeb1c4328
  19bc6c:       c30a36e2        .word   0xc30a36e2  19bc70:       020001bb        .word   0x020001bb
  19bc74:       000101fd        .word   0x000101fd
  19bc78:       02000137        .word   0x02000137

I can also reproduce with current master, although the generated code looks slightly different:

0012b410 <System_TimeSpan_Interval_double_int>:
  12b410:       e92d4830        push    {r4, r5, fp, lr}
  12b414:       e24dd008        sub     sp, sp, #8
  12b418:       e3a0c6ff        mov     ip, #267386880  ; 0xff00000
  12b41c:       e1a04000        mov     r4, r0
  12b420:       e3c30102        bic     r0, r3, #-2147483648    ; 0x80000000
  12b424:       e38cc207        orr     ip, ip, #1879048192     ; 0x70000000
  12b428:       e2721000        rsbs    r1, r2, #0
  12b42c:       e0dc0000        sbcs    r0, ip, r0
  12b430:       3a000028        bcc     12b4d8 <System_TimeSpan_Interval_double_int+0xc8>
  12b434:       ec432b11        vmov    d1, r2, r3
  12b438:       e59d0018        ldr     r0, [sp, #24]
  12b43c:       eeb51bc0        vcmpe.f64       d1, #0.0
  12b440:       eef1fa10        vmrs    APSR_nzcv, fpscr
  12b444:       ee000a10        vmov    s0, r0
  12b448:       eeb82bc0        vcvt.f64.s32    d2, s0
  12b44c:       e28f00a4        add     r0, pc, #164    ; 0xa4
  12b450:       a2800008        addge   r0, r0, #8
  12b454:       ed900b00        vldr    d0, [r0]
  12b458:       ee020b01        vmla.f64        d0, d2, d1
  12b45c:       ed9f1b29        vldr    d1, [pc, #164]  ; 12b508 <System_TimeSpan_Interval_double_int+0xf8>
  12b460:       eeb40bc1        vcmpe.f64       d0, d1
  12b464:       eef1fa10        vmrs    APSR_nzcv, fpscr
  12b468:       ca000011        bgt     12b4b4 <System_TimeSpan_Interval_double_int+0xa4>
  12b46c:       ed9f1b27        vldr    d1, [pc, #156]  ; 12b510 <System_TimeSpan_Interval_double_int+0x100>
  12b470:       eeb40bc1        vcmpe.f64       d0, d1
  12b474:       eef1fa10        vmrs    APSR_nzcv, fpscr
  12b478:       4a00000d        bmi     12b4b4 <System_TimeSpan_Interval_double_int+0xa4>
  12b47c:       eb12c4ff        bl      5dc880 <plt__jit_icall___emul_fconv_to_i8>
  12b480:       e3a02e71        mov     r2, #1808       ; 0x710
  12b484:       e3a03000        mov     r3, #0
  12b488:       e3822a02        orr     r2, r2, #8192   ; 0x2000
  12b48c:       e3a05000        mov     r5, #0
  12b490:       eb12bd6e        bl      5daa50 <plt__jit_icall___emul_lmul>
  12b494:       e58d5004        str     r5, [sp, #4]
  12b498:       e58d5000        str     r5, [sp]
  12b49c:       e58d1004        str     r1, [sp, #4]
  12b4a0:       e58d0000        str     r0, [sp]
  12b4a4:       e8840003        stm     r4, {r0, r1}
  12b4a8:       e28dd008        add     sp, sp, #8
  12b4ac:       e8bd4830        pop     {r4, r5, fp, lr}
  12b4b0:       e1a0f00e        mov     pc, lr
  12b4b4:       e3a00083        mov     r0, #131        ; 0x83
  12b4b8:       e3800c8b        orr     r0, r0, #35584  ; 0x8b00
  12b4bc:       eb12b45b        bl      5d8630 <plt__jit_icall_mono_helper_ldstr_mscorlib>
  12b4c0:       e1a01000        mov     r1, r0
  12b4c4:       e3a000b3        mov     r0, #179        ; 0xb3
  12b4c8:       e3800402        orr     r0, r0, #33554432       ; 0x2000000
  12b4cc:       e2800075        add     r0, r0, #117    ; 0x75
  12b4d0:       eb12b47a        bl      5d86c0 <plt__jit_icall_mono_create_corlib_exception_1>
  12b4d4:       eb12b45d        bl      5d8650 <plt__jit_icall_mono_arch_throw_exception>
  12b4d8:       e3a0004e        mov     r0, #78 ; 0x4e
  12b4dc:       e3800c8d        orr     r0, r0, #36096  ; 0x8d00
  12b4e0:       eb12b452        bl      5d8630 <plt__jit_icall_mono_helper_ldstr_mscorlib>
  12b4e4:       e1a01000        mov     r1, r0
  12b4e8:       e3a000b3        mov     r0, #179        ; 0xb3
  12b4ec:       e3800402        orr     r0, r0, #33554432       ; 0x2000000
  12b4f0:       eb12b472        bl      5d86c0 <plt__jit_icall_mono_create_corlib_exception_1>
  12b4f4:       eb12b455        bl      5d8650 <plt__jit_icall_mono_arch_throw_exception>
  12b4f8:       00000000        andeq   r0, r0, r0
  12b4fc:       bfe00000        svclt   0x00e00000
  12b500:       00000000        andeq   r0, r0, r0
  12b504:       3fe00000        svccc   0x00e00000
  12b508:       eb1c4328        bl      83c1b0 <__bss_end__+0x12184c>
  12b50c:       430a36e2        movwmi  r3, #42722      ; 0xa6e2
  12b510:       eb1c4328        bl      83c1b8 <__bss_end__+0x121854>
  12b514:       c30a36e2        movwgt  r3, #42722      ; 0xa6e2

@timmi-on-rails as a workaround until it is fixed, I suggest to use -O=-aot. You can set export MONO_ENV_OPTIONS='-O=-aot' so it will picked up by all programs using mono.

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 25, 2018

@lewurm Thank you for your effort. When you say you can reproduce with the current master, do you mean the apt upgrade procedure or is there actually a bug besides the upgrade scripts?
Because for me the workaround is simply remove mono and install it again and it works.
The issue only appears if I upgrade with apt upgrade from a previous mono version e.g. 5.14 -> 5.16

Maybe the step during apt upgrade when the BCL gets AOT compiled happens too early, when not all packages are installed/ set up? I will try to AOT recompile the BCL manually and see if that solves the problem. Then this would be a great workaround, if people don't need to completely reinstall mono, because this can take up to an hour on raspberry pi 2.

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 25, 2018

@timmi-on-rails with current master I mean that I built mono myself from source, and invoking the AOT compiler for mscorlib.dll similar to what apt would do. I'm pretty sure it's a bug with our LLVM support, nothing wrong with the packaging imho (except maybe that it shouldn't ship it with LLVM 😛 ).

Could you try my recommended workaround export MONO_ENV_OPTIONS='-O=-aot'?

Some observation: I applied the following patch to corefx:

--- a/src/Common/src/CoreLib/System/TimeSpan.cs
+++ b/src/Common/src/CoreLib/System/TimeSpan.cs
@@ -240,6 +240,8 @@ namespace System
 
         private static TimeSpan Interval(double value, int scale)
         {
+                       Console.WriteLine ("Interval arg1: " + value);
+                       Console.WriteLine ("Interval arg2: " + scale);
             if (Double.IsNaN(value))
                 throw new ArgumentException(SR.Arg_CannotBeNaN);
             double tmp = value * scale;
root@xam-jetsontx1-5:/mono# cat repro.cs
using System;

namespace Test
{
  class Program
  {
    public static void Main()
    {
      var ts = TimeSpan.FromMilliseconds(1);
    }
  }
}
root@xam-jetsontx1-5:/mono# ./mono/mini/mono-sgen -O=-aot repro.exe 
Interval arg1: 1
Interval arg2: 1
root@xam-jetsontx1-5:/mono# ./mono/mini/mono-sgen repro.exe
Interval arg1: 0
Interval arg2: 1

Unhandled Exception:
System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0xf4dc5360 + 0x00134> in <ef044d2be74a4446b7f7ca39b9cf8a11>:0 
  at System.TimeSpan.FromMilliseconds (System.Double value) <0xf4dc54dc + 0x0001b> in <ef044d2be74a4446b7f7ca39b9cf8a11>:0 
  at Test.Program.Main () [0x00000] in <e5506ae5acd740c1b4ebcd6ec7c2d35c>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.OverflowException: TimeSpan overflowed because the duration is too long.
  at System.TimeSpan.Interval (System.Double value, System.Int32 scale) <0xf4dc5360 + 0x00134> in <ef044d2be74a4446b7f7ca39b9cf8a11>:0 
  at System.TimeSpan.FromMilliseconds (System.Double value) <0xf4dc54dc + 0x0001b> in <ef044d2be74a4446b7f7ca39b9cf8a11>:0 
  at Test.Program.Main () [0x00000] in <e5506ae5acd740c1b4ebcd6ec7c2d35c>:0 

There seems to be a problem with argument passing, looks like some ABI mismatch between LLVM and mono. It's seriously broken.

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Oct 25, 2018

@lewurm I will check the things you said as soon as I can. Meanwhile do you have any explanation why reinstalling mono fixes the issue?

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 25, 2018

@timmi-on-rails what do you mean by "reinstalling"? As far as I understand, this problem starts to show up with version 5.16. As far as I know, that's the first version where we started to ship with LLVM support on linux. @directhex can you confirm that?

@lewurm lewurm self-assigned this Nov 6, 2018
luhenry added a commit to mono/llvm that referenced this issue Nov 7, 2018
Mono's LLVM backend was always emitting code like this:

> 000d7234 <double_ToString>:
>    d7234:       e92d4800        push    {fp, lr}
>    d7238:       ed2d8b02        vpush   {d8}
>    d723c:       ed908b00        vldr    d8, [r0]
>    d7240:       eb12e4e2        bl      5905d0 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d7244:       e1a03000        mov     r3, r0
>    d7248:       ec510b18        vmov    r0, r1, d8
>    d724c:       e3a02000        mov     r2, #0
>    d7250:       eb12e91a        bl      5916c0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d7254:       ecbd8b02        vpop    {d8}
>    d7258:       e8bd8800        pop     {fp, pc}

despite the correct setting passed to `llc`. Note that passing the floating
point value (`d8`) in the integer registers `r0` and `r1` is wrong.

With this change we get the following:

> 000d9934 <double_ToString>:
>    d9934:       e92d4800        push    {fp, lr}
>    d9938:       ed2d8b02        vpush   {d8}
>    d993c:       ed908b00        vldr    d8, [r0]
>    d9940:       eb137c2e        bl      5b8a00 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d9944:       eeb00b48        vmov.f64        d0, d8
>    d9948:       e1a01000        mov     r1, r0
>    d994c:       e3a00000        mov     r0, #0
>    d9950:       eb138066        bl      5b9af0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d9954:       ecbd8b02        vpop    {d8}
>    d9958:       e8bd4800        pop     {fp, lr}
>    d995c:       e1a0f00e        mov     pc, lr

Which matches with what the Mono JIT emits:

>   0:   e92d4100        push    {r8, lr}
>   4:   e24dd028        sub     sp, sp, #40     ; 0x28
>   8:   e58d0018        str     r0, [sp, #24]
>   c:   e59d0018        ldr     r0, [sp, #24]
>  10:   ed900b00        vldr    d0, [r0]
>  14:   ed8d0b08        vstr    d0, [sp, #32]
>  18:   eb00000e        bl      0x58
>  1c:   e1a01000        mov     r1, r0
>  20:   ed9d0b08        vldr    d0, [sp, #32]
>  24:   e3a00000        mov     r0, #0
>  28:   eb000007        bl      0x4c
>  2c:   e28dd028        add     sp, sp, #40     ; 0x28
>  30:   e8bd8100        pop     {r8, pc}

Both are passing the floating point argument correctly via `d0`.

Fixes mono/mono#11095
lewurm added a commit to mono/llvm that referenced this issue Nov 8, 2018
Mono's LLVM backend was always emitting code like this:

> 000d7234 <double_ToString>:
>    d7234:       e92d4800        push    {fp, lr}
>    d7238:       ed2d8b02        vpush   {d8}
>    d723c:       ed908b00        vldr    d8, [r0]
>    d7240:       eb12e4e2        bl      5905d0 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d7244:       e1a03000        mov     r3, r0
>    d7248:       ec510b18        vmov    r0, r1, d8
>    d724c:       e3a02000        mov     r2, #0
>    d7250:       eb12e91a        bl      5916c0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d7254:       ecbd8b02        vpop    {d8}
>    d7258:       e8bd8800        pop     {fp, pc}

despite the correct setting passed to `llc`. Note that passing the floating
point value (`d8`) in the integer registers `r0` and `r1` is wrong.

With this change we get the following:

> 000d9934 <double_ToString>:
>    d9934:       e92d4800        push    {fp, lr}
>    d9938:       ed2d8b02        vpush   {d8}
>    d993c:       ed908b00        vldr    d8, [r0]
>    d9940:       eb137c2e        bl      5b8a00 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d9944:       eeb00b48        vmov.f64        d0, d8
>    d9948:       e1a01000        mov     r1, r0
>    d994c:       e3a00000        mov     r0, #0
>    d9950:       eb138066        bl      5b9af0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d9954:       ecbd8b02        vpop    {d8}
>    d9958:       e8bd4800        pop     {fp, lr}
>    d995c:       e1a0f00e        mov     pc, lr

Which matches with what the Mono JIT emits:

>   0:   e92d4100        push    {r8, lr}
>   4:   e24dd028        sub     sp, sp, #40     ; 0x28
>   8:   e58d0018        str     r0, [sp, #24]
>   c:   e59d0018        ldr     r0, [sp, #24]
>  10:   ed900b00        vldr    d0, [r0]
>  14:   ed8d0b08        vstr    d0, [sp, #32]
>  18:   eb00000e        bl      0x58
>  1c:   e1a01000        mov     r1, r0
>  20:   ed9d0b08        vldr    d0, [sp, #32]
>  24:   e3a00000        mov     r0, #0
>  28:   eb000007        bl      0x4c
>  2c:   e28dd028        add     sp, sp, #40     ; 0x28
>  30:   e8bd8100        pop     {r8, pc}

Both are passing the floating point argument correctly via `d0`.

Fixes mono/mono#11095
@lewurm lewurm reopened this Nov 8, 2018
directhex added a commit to mono/linux-packaging-mono-llvm that referenced this issue Nov 8, 2018
luhenry added a commit that referenced this issue Nov 8, 2018
Commit list for mono/llvm:

* mono/llvm@c975102 [mono] respect hardfloat/softloat setting in ARM ABI (#16)

Diff: mono/llvm@8415fd8...c975102


Fixes #11095
@directhex

This comment has been minimized.

Copy link
Contributor

@directhex directhex commented Nov 9, 2018

If you're on the preview repo, try updating the mono-llvm-tools package. The new build should include a fix for this.

@directhex directhex reopened this Nov 9, 2018
@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Nov 10, 2018

@lewurm fixed the LLVM bug, but what about the install/update script issue, that I described?

@directhex

This comment has been minimized.

Copy link
Contributor

@directhex directhex commented Nov 12, 2018

I'm not sure your description makes sense. Apt unpacks everything before configuring anything, so AOT will happen after LLVM is on disk (and therefore after --aot=try-llvm is okay to use), even if the mono-llvm-support package gets configured after libmono-corlib4.5-cil

One change I've made is LLVM should now only be suggested (non-default) on ARM platforms.

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Nov 14, 2018

@directhex I thought so aswell, this is why I attached the log files of the installation processes to prove that the compilation happens before everything is unpacked. (See my comment and press the black triangles to unfold the installation logs).
So is this is even an aptitude bug?

@directhex

This comment has been minimized.

Copy link
Contributor

@directhex directhex commented Nov 15, 2018

... huh. Looking at your log, I think you're right. It's due to the use of Pre-Depends in ca-certificates-mono, which forces mono-runtime-common to be installed and configured before ca-certificates-mono can be unpacked. But that forces the smallest possible dependency chain for mono-runtime-common to be installed/configured before anything else starts, which means enough Mono for gacutil to run (considered the bare-minimum base set for Mono packaging), which means the corlib. So, yes, as you surmised, it is happening how you thought.

Roslyn is likely being LLVM-AOT'd, but corlib is classic AOT.

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Nov 15, 2018

@directhex Thank you for verifying and the detailed explanation. Should I open another issue for this?

@directhex

This comment has been minimized.

Copy link
Contributor

@directhex directhex commented Nov 15, 2018

Yeah, I guess. I'll need to consult with smarter people than me on how to fix it.

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Nov 19, 2018

Could you, @timmi-on-rails, or someone else confirm that the new package fixes this issue? Thanks

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Nov 19, 2018

@lewurm Do I need to compile from source or are there precompiled packages available? If there are precompiled packages, then I will check it this week.

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Nov 19, 2018

@timmi-on-rails the fix is included in the preview repository #11095 (comment)

@timmi-on-rails

This comment has been minimized.

Copy link

@timmi-on-rails timmi-on-rails commented Dec 1, 2018

@lewurm Sorry for the delay. I tested the preview version today and it worked.
No errors, when using the mono-llvm-support. (I manually called dpkg-reconfigure libmono-corlib4.5-cil upfront to make sure the mscorlib is AOT'd with llvm.)

Tested mono version:

Mono JIT compiler version 5.18.0.209 (tarball Sat Nov 24 09:39:13 UTC 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug
        Interpreter:   yes
        LLVM:          yes(600)
        Suspend:       preemptive
        GC:            sgen (concurrent by default)
@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Dec 3, 2018

Thanks for the confirmation @timmi-on-rails. I'll close the issue 🙂

@lewurm lewurm closed this Dec 3, 2018
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Apr 24, 2019
Bumps to mono/api-snapshot@ae01378
Bumps to mono/reference-assemblies@e5173a5
Bumps to mono/bockbuild@d30329d
Bumps to mono/boringssl@3d87996
Bumps to mono/corefx@72f7d76
Bumps to mono/corert@1b7d4a1
Bumps to mono/helix-binaries@7e893ea
Bumps to mono/illinker-test-assets@f21ff68
Bumps to mono/linker@13d864e
Bumps to mono/llvm@1aaaaa5 [mono]
Bumps to mono/llvm@2c2cffe [xamarin-android]
Bumps to mono/NUnitLite@0029561
Bumps to mono/roslyn-binaries@0bbc9b4
Bumps to mono/xunit-binaries@8f6e62e

	$ git diff --shortstat 886c4901..e66c7667      # mono
        3597 files changed, 350850 insertions(+), 91128 deletions(-)
	$ git diff --shortstat 349752c464c5fc93b32e7d45825f2890c85c8b7d..2c2cffedf01e0fe266b9aaad2c2563e05b750ff4
	 240 files changed, 18562 insertions(+), 6581 deletions(-)

Context: dotnet/coreclr#22046

Fixes: CVE 2018-8292 on macOS
Fixes: http://work.devdiv.io/737323
Fixes: dotnet/corefx#33965
Fixes: dotnet/standard#642
Fixes: mono/mono#6997
Fixes: mono/mono#7326
Fixes: mono/mono#7517
Fixes: mono/mono#7750
Fixes: mono/mono#7859
Fixes: mono/mono#8360
Fixes: mono/mono#8460
Fixes: mono/mono#8766
Fixes: mono/mono#8922
Fixes: mono/mono#9418
Fixes: mono/mono#9507
Fixes: mono/mono#9951
Fixes: mono/mono#10024
Fixes: mono/mono#10030
Fixes: mono/mono#10038
Fixes: mono/mono#10448
Fixes: mono/mono#10735
Fixes: mono/mono#10735
Fixes: mono/mono#10737
Fixes: mono/mono#10743
Fixes: mono/mono#10834
Fixes: mono/mono#10837
Fixes: mono/mono#10838
Fixes: mono/mono#10863
Fixes: mono/mono#10945
Fixes: mono/mono#11020
Fixes: mono/mono#11021
Fixes: mono/mono#11021
Fixes: mono/mono#11049
Fixes: mono/mono#11091
Fixes: mono/mono#11095
Fixes: mono/mono#11123
Fixes: mono/mono#11138
Fixes: mono/mono#11146
Fixes: mono/mono#11202
Fixes: mono/mono#11214
Fixes: mono/mono#11317
Fixes: mono/mono#11326
Fixes: mono/mono#11378
Fixes: mono/mono#11385
Fixes: mono/mono#11478
Fixes: mono/mono#11479
Fixes: mono/mono#11488
Fixes: mono/mono#11489
Fixes: mono/mono#11527
Fixes: mono/mono#11529
Fixes: mono/mono#11596
Fixes: mono/mono#11603
Fixes: mono/mono#11613
Fixes: mono/mono#11623
Fixes: mono/mono#11663
Fixes: mono/mono#11681
Fixes: mono/mono#11684
Fixes: mono/mono#11693
Fixes: mono/mono#11697
Fixes: mono/mono#11779
Fixes: mono/mono#11809
Fixes: mono/mono#11858
Fixes: mono/mono#11895
Fixes: mono/mono#11898
Fixes: mono/mono#11898
Fixes: mono/mono#11965
Fixes: mono/mono#12182
Fixes: mono/mono#12193
Fixes: mono/mono#12218
Fixes: mono/mono#12235
Fixes: mono/mono#12263
Fixes: mono/mono#12307
Fixes: mono/mono#12331
Fixes: mono/mono#12362
Fixes: mono/mono#12374
Fixes: mono/mono#12402
Fixes: mono/mono#12421
Fixes: mono/mono#12461
Fixes: mono/mono#12479
Fixes: mono/mono#12479
Fixes: mono/mono#12552
Fixes: mono/mono#12603
Fixes: mono/mono#12747
Fixes: mono/mono#12831
Fixes: mono/mono#12843
Fixes: mono/mono#12881
Fixes: mono/mono#13030
Fixes: mono/mono#13284
Fixes: mono/mono#13297
Fixes: mono/mono#13455
Fixes: mono/mono#13460
Fixes: mono/mono#13478
Fixes: mono/mono#13479
Fixes: mono/mono#13522
Fixes: mono/mono#13607
Fixes: mono/mono#13610
Fixes: mono/mono#13610
Fixes: mono/mono#13639
Fixes: mono/mono#13672
Fixes: mono/mono#13834
Fixes: mono/mono#13878
Fixes: mono/mono#6352
Fixes: mono/monodevelop#6898
Fixes: xamarin/maccore#1069
Fixes: xamarin/maccore#1407
Fixes: xamarin/maccore#604
Fixes: xamarin/xamarin-macios#4984
Fixes: xamarin/xamarin-macios#5289
Fixes: xamarin/xamarin-macios#5363
Fixes: xamarin/xamarin-macios#5381
Fixes: https://issuetracker.unity3d.com/issues/editor-crashes-with-g-logv-when-entering-play-mode-with-active-flowcanvas-script
vargaz added a commit to mono/llvm that referenced this issue Oct 1, 2019
Mono's LLVM backend was always emitting code like this:

> 000d7234 <double_ToString>:
>    d7234:       e92d4800        push    {fp, lr}
>    d7238:       ed2d8b02        vpush   {d8}
>    d723c:       ed908b00        vldr    d8, [r0]
>    d7240:       eb12e4e2        bl      5905d0 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d7244:       e1a03000        mov     r3, r0
>    d7248:       ec510b18        vmov    r0, r1, d8
>    d724c:       e3a02000        mov     r2, #0
>    d7250:       eb12e91a        bl      5916c0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d7254:       ecbd8b02        vpop    {d8}
>    d7258:       e8bd8800        pop     {fp, pc}

despite the correct setting passed to `llc`. Note that passing the floating
point value (`d8`) in the integer registers `r0` and `r1` is wrong.

With this change we get the following:

> 000d9934 <double_ToString>:
>    d9934:       e92d4800        push    {fp, lr}
>    d9938:       ed2d8b02        vpush   {d8}
>    d993c:       ed908b00        vldr    d8, [r0]
>    d9940:       eb137c2e        bl      5b8a00 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d9944:       eeb00b48        vmov.f64        d0, d8
>    d9948:       e1a01000        mov     r1, r0
>    d994c:       e3a00000        mov     r0, #0
>    d9950:       eb138066        bl      5b9af0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d9954:       ecbd8b02        vpop    {d8}
>    d9958:       e8bd4800        pop     {fp, lr}
>    d995c:       e1a0f00e        mov     pc, lr

Which matches with what the Mono JIT emits:

>   0:   e92d4100        push    {r8, lr}
>   4:   e24dd028        sub     sp, sp, #40     ; 0x28
>   8:   e58d0018        str     r0, [sp, #24]
>   c:   e59d0018        ldr     r0, [sp, #24]
>  10:   ed900b00        vldr    d0, [r0]
>  14:   ed8d0b08        vstr    d0, [sp, #32]
>  18:   eb00000e        bl      0x58
>  1c:   e1a01000        mov     r1, r0
>  20:   ed9d0b08        vldr    d0, [sp, #32]
>  24:   e3a00000        mov     r0, #0
>  28:   eb000007        bl      0x4c
>  2c:   e28dd028        add     sp, sp, #40     ; 0x28
>  30:   e8bd8100        pop     {r8, pc}

Both are passing the floating point argument correctly via `d0`.

Fixes mono/mono#11095
directhex added a commit to dotnet/llvm-project that referenced this issue Nov 7, 2019
Mono's LLVM backend was always emitting code like this:

> 000d7234 <double_ToString>:
>    d7234:       e92d4800        push    {fp, lr}
>    d7238:       ed2d8b02        vpush   {d8}
>    d723c:       ed908b00        vldr    d8, [r0]
>    d7240:       eb12e4e2        bl      5905d0 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d7244:       e1a03000        mov     r3, r0
>    d7248:       ec510b18        vmov    r0, r1, d8
>    d724c:       e3a02000        mov     r2, #0
>    d7250:       eb12e91a        bl      5916c0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d7254:       ecbd8b02        vpop    {d8}
>    d7258:       e8bd8800        pop     {fp, pc}

despite the correct setting passed to `llc`. Note that passing the floating
point value (`d8`) in the integer registers `r0` and `r1` is wrong.

With this change we get the following:

> 000d9934 <double_ToString>:
>    d9934:       e92d4800        push    {fp, lr}
>    d9938:       ed2d8b02        vpush   {d8}
>    d993c:       ed908b00        vldr    d8, [r0]
>    d9940:       eb137c2e        bl      5b8a00 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d9944:       eeb00b48        vmov.f64        d0, d8
>    d9948:       e1a01000        mov     r1, r0
>    d994c:       e3a00000        mov     r0, #0
>    d9950:       eb138066        bl      5b9af0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d9954:       ecbd8b02        vpop    {d8}
>    d9958:       e8bd4800        pop     {fp, lr}
>    d995c:       e1a0f00e        mov     pc, lr

Which matches with what the Mono JIT emits:

>   0:   e92d4100        push    {r8, lr}
>   4:   e24dd028        sub     sp, sp, #40     ; 0x28
>   8:   e58d0018        str     r0, [sp, llvm#24]
>   c:   e59d0018        ldr     r0, [sp, llvm#24]
>  10:   ed900b00        vldr    d0, [r0]
>  14:   ed8d0b08        vstr    d0, [sp, llvm#32]
>  18:   eb00000e        bl      0x58
>  1c:   e1a01000        mov     r1, r0
>  20:   ed9d0b08        vldr    d0, [sp, llvm#32]
>  24:   e3a00000        mov     r0, #0
>  28:   eb000007        bl      0x4c
>  2c:   e28dd028        add     sp, sp, #40     ; 0x28
>  30:   e8bd8100        pop     {r8, pc}

Both are passing the floating point argument correctly via `d0`.

Fixes mono/mono#11095
directhex added a commit to dotnet/llvm-project that referenced this issue Nov 7, 2019
Mono's LLVM backend was always emitting code like this:

> 000d7234 <double_ToString>:
>    d7234:       e92d4800        push    {fp, lr}
>    d7238:       ed2d8b02        vpush   {d8}
>    d723c:       ed908b00        vldr    d8, [r0]
>    d7240:       eb12e4e2        bl      5905d0 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d7244:       e1a03000        mov     r3, r0
>    d7248:       ec510b18        vmov    r0, r1, d8
>    d724c:       e3a02000        mov     r2, #0
>    d7250:       eb12e91a        bl      5916c0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d7254:       ecbd8b02        vpop    {d8}
>    d7258:       e8bd8800        pop     {fp, pc}

despite the correct setting passed to `llc`. Note that passing the floating
point value (`d8`) in the integer registers `r0` and `r1` is wrong.

With this change we get the following:

> 000d9934 <double_ToString>:
>    d9934:       e92d4800        push    {fp, lr}
>    d9938:       ed2d8b02        vpush   {d8}
>    d993c:       ed908b00        vldr    d8, [r0]
>    d9940:       eb137c2e        bl      5b8a00 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
>    d9944:       eeb00b48        vmov.f64        d0, d8
>    d9948:       e1a01000        mov     r1, r0
>    d994c:       e3a00000        mov     r0, #0
>    d9950:       eb138066        bl      5b9af0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
>    d9954:       ecbd8b02        vpop    {d8}
>    d9958:       e8bd4800        pop     {fp, lr}
>    d995c:       e1a0f00e        mov     pc, lr

Which matches with what the Mono JIT emits:

>   0:   e92d4100        push    {r8, lr}
>   4:   e24dd028        sub     sp, sp, #40     ; 0x28
>   8:   e58d0018        str     r0, [sp, llvm#24]
>   c:   e59d0018        ldr     r0, [sp, llvm#24]
>  10:   ed900b00        vldr    d0, [r0]
>  14:   ed8d0b08        vstr    d0, [sp, llvm#32]
>  18:   eb00000e        bl      0x58
>  1c:   e1a01000        mov     r1, r0
>  20:   ed9d0b08        vldr    d0, [sp, llvm#32]
>  24:   e3a00000        mov     r0, #0
>  28:   eb000007        bl      0x4c
>  2c:   e28dd028        add     sp, sp, #40     ; 0x28
>  30:   e8bd8100        pop     {r8, pc}

Both are passing the floating point argument correctly via `d0`.

Fixes mono/mono#11095
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.