Questions about Liftoff compiler and Wasm frames

[zhaojia...@loongson.cn]

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 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. But arm64 just use a 32-bit store, why it's high 32 bits are clean?

Thanks inadvance!

[Clemens Backes]

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), so you might need to pick a revision without that problem.

-Clemens

--
--
v8-dev mailing list
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/27de5d50-12c5-4735-beee-67e04024b42dn%40googlegroups.com.

--

Clemens Backes

Software Engineer

clem...@google.com

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.

[Zhao Jiazhong]

Hi Clemens,

Thanks for your reply, I 'm not sure what information do you want by running with --code-comments, should it be used to print comments with --print-code? If so, I didn't use the --print-code, because it's will produce so many logs.

The size of log file grew to hundreds of MBs and the benchmark was not even start when I gave up.

I found the specific instructions in gdb by adding breakpoints in JIT code when instruction streams match some patterns. It's indeed inefficient,  but I don't know any better methods, and if there is not an arm64 machine to compare, I have no idea

how to locate the bug. Anyway, I am compiling the v8_wasm_compile_fuzzer, maybe it will help.

Besides, I find that somtimes the high 32 bits of the value on arm64 is not clean too, so it's just because mips64 needs a sign-extension operation somewhere?

Thanks,

Zhao Jiazhong

[Clemens Backes]

Hi Zhao,

I think once we know which instruction we are actually generating code for, it should be easier to tell whether we should use 32-bit or 64-bit memory operations. Code comments should tell you which wasm instruction we are in (Liftoff just emits a comment with the current opcode before starting to emit code for that opcode).

Note that code comments only work if the v8_code_comments gn arg is set, which is the default in debug builds.

Once you enable code comments, you will always see them when disassembling code in v8, e.g. via the jco gdb command from our own gdbinit file (just include that file by adding a "source /path/to/v8/tools/gdbinit" line to your $HOME/.gdbinit file). If you include that file, you can just use "jco <address>" (or "jco $rip" on x64) and it will disassemble the function around that address.

Without the gdbinit, you can also just call the _v8_internal_Print_Code function and pass the address, of course.

Hope that helps!

-Clemens

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/9c86c79c-e36c-4981-8def-08b00ca764fdn%40googlegroups.com.

[Zhao Jiazhong]

Hi Clemens,

I tried to build chrome90 with `v8_enable_debugging_features = true`, but the "jco" command still said 'No symbol "_v8_internal_Print_Code" in current context'. It seems that this symbol exists in d8 but not in chrome, both of them are release builds.

Currently I can't run the benchmark with d8, so could the v8/tools/gdbinit file be used in chrome? Or should I set more gn args? Thanks!

Best regards,

Zhao Jiazhong

[Clemens Backes]

I think I used the "jco" gdb command also in chrome (in a renderer process, obviously). I just source V8's gdbinit from my global ~/.gdbinit.

The gn args you need are "v8_code_comments = true" and "v8_enable_disassembler = true".

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/e6cd9efc-ff90-4218-9f12-0deb8e5f31fcn%40googlegroups.com.