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".

On Tue, Jun 29, 2021 at 8:22 AM Zhao Jiazhong <zhaojiazhong...@loongson.cn>
wrote:

> 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
> <https://groups.google.com/d/msgid/v8-dev/e6cd9efc-ff90-4218-9f12-0deb8e5f31fcn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 

Clemens Backes

Software Engineer

cleme...@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/CAGO%3DqhCeRSE6Nc81u8FUo9D7874N7ryAL0M6y9dpB5bPH-kk%3Dg%40mail.gmail.com.

Reply via email to