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 On Saturday, June 26, 2021 at 1:42:15 AM UTC+8 Clemens Backes wrote: > 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 > <https://source.chromium.org/chromium/chromium/src/+/main:v8/tools/gdbinit;l=34;drc=42409a2e69fb126bc0ec0ff0f4e71d3df043811d> > > 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 > <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/diagnostics/objects-printer.cc;l=2858;drc=4e19455bd82d062996917449c4d740cc34477bd9> > > function and pass the address, of course. > > Hope that helps! > > -Clemens > > On Thu, Jun 24, 2021 at 3:47 PM Zhao Jiazhong <zhaojia...@loongson.cn> > wrote: > >> 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 >> On Thursday, June 24, 2021 at 6:31:56 PM UTC+8 Clemens Backes wrote: >> >>> 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 zhaojia...@loongson.cn < >>> zhaojia...@loongson.cn> 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 >>>> 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 >>>> >>>> <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 >>> >>> 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. >>> >>> -- >> -- >> 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/9c86c79c-e36c-4981-8def-08b00ca764fdn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/9c86c79c-e36c-4981-8def-08b00ca764fdn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > 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. > > -- -- v8-dev mailing list v8-dev@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/e6cd9efc-ff90-4218-9f12-0deb8e5f31fcn%40googlegroups.com.
