在V8中调试CodeStubAssembler(CSA)代码 [英] Debugging CodeStubAssembler (CSA) code in V8

问题描述

我目前正在尝试调试V8中的某些 CodeStubAssembler 内置文件.

I am currently trying to debug some CodeStubAssembler builtins in V8.

如果我正确理解的话，CSA只是花哨的C ++代码，可以有效地为不同平台生成汇编指令.

If I understood it correctly, CSA is just fancy C++ code that efficiently generates assembly instructions for different platforms.

但是，即使在调试版本上，我也不能在 builtins/*-gen.cc 文件中的任何代码上使用 gdb 设置断点.既不通过在文件和源代码行上设置断点，也不通过尝试破坏函数名来实现.通过在目标文件上运行 objdump -D 来进行反汇编的唯一方法.但是我想在运行时看到它.

However, even on a debug build I can not set breakpoints with gdb on any code in the builtins/*-gen.cc files. Neither by setting a breakpoint on the file and source line, nor by trying to break on the function names. The only thing that works to get a disassembly by running objdump -D on the object file. But I'd like to see it while running.

是否可以以某种方式在CSA生成的内置文件上设置断点?

Is it possible to somehow set breakpoints on the builtins generated by CSA?

推荐答案

V8开发人员在此处.实际上，CSA 生成了汇编代码.当 mksnapshot 二进制文件在V8的构建过程中运行时，它便会这样做.CSA代码本身不包含在最终二进制文件( d8 或 libv8.so )中，仅包含在其输出中.因此，CSA代码运行的时间与生成的内置程序运行的时间完全不同.

V8 developer here. CSA generates assembly code, indeed. It does so when the mksnapshot binary runs as part of V8's build process. The CSA code itself is not contained in the final binary (d8 or libv8.so), only its output. So the time when the CSA code runs is entirely different from the time when the generated builtins run.

结果是:

• 您可以像在任何其他C ++代码上一样在CSA代码上设置断点-如果您在调试器中运行 mksnapshot 二进制文件(或者如果您在不使用快照的情况下编译V8，那就是(1)启动时超级慢，(2)已弃用.然后，您将逐步浏览CSA代码，因为它会发出Turbofan IR图，然后Turbofan后端将其转换为机器代码.

• You can put a breakpoint on CSA code like on any other C++ code -- if you run the mksnapshot binary in your debugger (or if you compile V8 without snapshot, but that's (1) super slow on startup and (2) deprecated). You can then step through the CSA code as it emits a Turbofan IR graph which the Turbofan backend will then translate to machine code.

您可以通过在CSA代码中放入 DebugBreak()指令并重新编译，从而在CSA生成的内置文件中添加断点.然后，您可以逐步查看生成的说明.请注意，将没有可用的(C ++或其他)源代码，您必须在GDB中使用"layout asm".

You can put a breakpoint into CSA-generated builtins by putting a DebugBreak() instruction into the CSA code and recompiling. You can then step through the generated instructions. Note that there will be no (C++ or other) source code available, you'll have to use "layout asm" in GDB.

如果您想使用GDB的功能将断点放入CSA生成的内置程序中，则必须以某种方式获取其地址(通过Isolate-> buildins可以做到这一点，但很麻烦)，并且然后在要中断的原始地址上放置一个断点.

If you wanted to use GDB's facilities to put a breakpoint into a CSA-generated builtin, you'd have to get its address somehow (it's possible, but cumbersome, to do that via isolate->builtins) and then put a breakpoint on the raw address where you want to break.

有时"printf调试"更方便.为此有 CodeStubAssembler :: Print(...).(请注意，CSA中的普通 printf 会在mksnapshot时执行，并且不会影响生成的内置函数；而 CSA :: Print 会将代码发射到生成的内置函数中，从而触发一个运行时的标准输出.这可能是我上面试图描述的效果的最有说明性的方式.)

Sometimes "printf debugging" is more convenient. There's CodeStubAssembler::Print(...) for this purpose. (Note that a plain printf in CSA would execute at mksnapshot time, and would not affect the generated builtin; whereas CSA::Print emits code into the generated builtin that will trigger an stdout-print at runtime. That's probably the most illustrative way to demonstrate the effects I tried to describe above.)

这篇关于在V8中调试CodeStubAssembler(CSA)代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！