Hi Zhao, it would be interesting to know what is actually being loaded here, and in the context of which instruction. We have seen inconsistencies between TurboFan and Liftoff before, which could lead to such errors, e.g. if Liftoff writes a 32-bit value to the stack and TurboFan reads it back as a 64-bit value.
Can you run with --code-comments and post the full code block starting from the last code comment before the error? Another thought: Debugging code generation issues in the context of such a big application is often difficult. Did you try running one of the fuzzers for a while to see if it finds you a smaller (and hence easier to understand) reproducer? You would need to compile e.g. the v8_wasm_compile_fuzzer target in chromium with gn arg use_libfuzzer = true, and then just run that binary for a while. The fuzzer currently has some issues (crbug/1219746 <https://crbug.com/1219746>), so you might need to pick a revision without that problem. -Clemens On Thu, Jun 24, 2021 at 11:44 AM [email protected] < [email protected]> wrote: > Hello everyone, > > I am debugging a bug in liftoff compiler on mips64 platform, but I'm not > very familiar with the Wasm frames layout, so I want some help, any advice > would be appreciated. Thanks in advance! > > When *#enable-webassembly-baseline *and *#enable-webassembly-tiering *are > *both* *enabled*, this Unity3d WebGL benchmark > <https://files.unity3d.com/marcot/benchmarks2018.2.5f1/> would report a > memory out of bound error on mips64 chromium 90. And I compared the mips64 > and arm64's execution and found a difference that leading to the error on > mips64 machine: > > They both load a 64-bit value from stack and compare it with another value > (both are 1), but arm64 use 32-bit register to do the comparison, and > mips64 use the full 64-bit register, which is because mips64 don't have > 32-bit registers. > > arm64: > Instructions: > => 0x49c131d490: add w1, w10, #0x1 > *0x49c131d494: ldr x10, [sp, #224]* > 0x49c131d498: cmp w1, *w10* > > Stack values: > 0xffffe2c756d0: 0x00000046085e8319 0x0000000000000008 > 0xffffe2c756e0: 0x0000ffffe2c75790 0x00000049c135d360 > *0xffffe2c756f0: 0x0000000000000001 * 0x000000000165e760 > 0xffffe2c75700: 0x0000000000000004 0x0000000000000000 > > mips64: > Instructions: > 0xc4e3e8e010: addi t0, t1, 1(0x1) > *0xc4e3e8e014: ld t1, fp,16(0x10)* > 0xc4e3e8e018: bne t0, t1, -1540(0x3f9fc) > > Stack values: > 0xfffb8389f0: 0x00000090b476a469 0x0000000000000008 > 0xfffb838a00: 0x000000fffb838aa0 0x0000003daed7909c > *0xfffb838a10: 0x0000009000000001 * 0x000000000164bd70 > 0xfffb838a20: 0x000000ff00000004 0x0000000000000000 > > I found that the low 32 bits of mips64 are also 1, but the high 32 bits > are not clean. > So the questions are: > 1) Should mips64 sign-extend the value before the comparison? Why would > it load a double word, when it actually need a word comparison? > 2) It seems that 32-bit values also take 64-bit slots, should the high 32 > bits keep clean? > 3) If the answer to 2) is yes, how do we ensure that? I could work around > this bug by use double word store when storing 32-bit values in > LiftoffStackSlots::Construct > <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/wasm/baseline/mips64/liftoff-assembler-mips64.h;l=3202>. > But arm64 just use a 32-bit store, why it's high 32 bits are clean? > > Thanks inadvance! > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/27de5d50-12c5-4735-beee-67e04024b42dn%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/27de5d50-12c5-4735-beee-67e04024b42dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Clemens Backes Software Engineer [email protected] Google Germany GmbH Erika-Mann-Straße 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAGO%3DqhAxQA_ky7Pj9h%3DsBNAigrQWxU5jMf0nEsHMak55vYe8_w%40mail.gmail.com.
