How can i debug the CodeStubAssembler(CSA) code in v8 line by line

I have seen the good answer to my quesntion from Debugging CodeStubAssembler (CSA) code in V8. howerver,i really cannot understand the point "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" in upshot one.Can I debug CSA line by line according to the source code in that way? In order to express my needs more clearly,I use some code examples:


2864 TNode<Smi> CodeStubAssembler::BuildAppendJSArray(ElementsKind kind,
2865                                               TNode<JSArray> array,
2866                                             CodeStubArguments* args,
2867                                             TVariable<IntPtrT>* arg_index,
2868                                             Label* bailout) {
2869 Comment("BuildAppendJSArray: ", ElementsKindToString(kind));
2870 Label pre_bailout(this);
2871 Label success(this);
2872 TVARIABLE(Smi, var_tagged_length);

The above is the code in CSA,Can I enter 'n' in gdb and then single step from line 2869 to line 2870 ?

Just to be clear,Can I get the following format for debugging CSA code?

[───────────────────────────────────────────────────────────────────────────────────────DISASM───────────────────────────────────────────────────────────────────────────────────────]
   0x7f9fc9bcaca5    mov    rax, qword ptr [rbp - 0x60]
   0x7f9fc9bcaca9    mov    rcx, qword ptr fs:[0x28]
   0x7f9fc9bcacb2    mov    rdx, qword ptr [rbp - 8]
   0x7f9fc9bcacb6    cmp    rcx, rdx
   0x7f9fc9bcacb9    mov    qword ptr [rbp - 0xb0], rax
 ► 0x7f9fc9bcacc0    jne    0x7f9fc9bcacd6
 
   0x7f9fc9bcacc6    mov    rax, qword ptr [rbp - 0xb0]
   0x7f9fc9bcaccd    add    rsp, 0xb0
   0x7f9fc9bcacd4    pop    rbp
   0x7f9fc9bcacd5    ret    
 
   0x7f9fc9bcacd6    call   __stack_chk_fail@plt          <0x7f9fcb191dc0>
[───────────────────────────────────────────────────────────────────────────────────────SOURCE───────────────────────────────────────────────────────────────────────────────────────]
457     // static
458     MaybeHandle<Object> Execution::Call(Isolate* isolate, Handle<Object> callable,
459                                         Handle<Object> receiver, int argc,
460                                         Handle<Object> argv[]) {
461       return Invoke(isolate, InvokeParams::SetUpForCall(isolate, callable, receiver,
462                                                         argc, argv));
463     }
464
465     MaybeHandle<Object> Execution::CallBuiltin(Isolate* isolate,
466                                                Handle<JSFunction> builtin,
[───────────────────────────────────────────────────────────────────────────────────────STACK

Solution

Yes, you can do that, just like for any other C++ code.

Of course, this code runs as part of mksnapshot, and what it does is it creates (part of) a "builtin" code object that can handle appending elements to JavaScript arrays. Line 2869 will put a comment into the code object's comment section (if you are running with the --code-comments flag), line 2870 will define a label that will be used for conditional jumps later.

So just to be clear, this code does not run when you actually append elements to arrays. At that time, the builtin generated by this code will run, and debugging that requires different techniques (see the other answer).

EDIT to address questions in comments:

If i enter p kind in line 2870,can i get the value of kind? if i enter p ElementsKindToString in this function,can i get the address of function ElementsKindToString?

Yes, of course, this is plain C++. (Also, why do you ask? Just try it!)

how could i break in gdb before the Turbofan backend translate this function to machine code and get the debugging format i posted above.

Run mksnapshot in GDB and set a breakpoint on the line you want, then switch the view mode as desired. (Again, this is regular GDB usage; if you need a GDB tutorial then please search for one, there are plenty on the 'net.)

While you haven't directly asked for it, I have a suspicion that what you really want to do is step through the generated builtins instruction-by-instruction and see the CSA source that was responsible for generating them. That, unfortunately, is not possible, because the builtins and their generators run at different times (and even in different binaries!).