Always insert preset commands when executing commands from DAP

[andyw8]

This is a workaround for ruby#900

We believe there is a race condition relating to the in_subsession? check here:

debug/lib/debug/session.rb

Lines 2578 to 2587 in d7bf3b2

	if ::DEBUGGER__::SESSION.in_subsession?
	if cmds
	commands = [*cmds[1], *cmds[2]].map{|c| c.split(';;').join("\n")}
	::DEBUGGER__::SESSION.add_preset_commands cmds[0], commands, kick: false, continue: false
	end
	else
	loc = caller_locations(up_level, 1).first; ::DEBUGGER__.add_line_breakpoint loc.path, loc.lineno + 1, oneshot: true, command: cmds
	end
	self
	end

By making this change we ensure that evaluate always acts as if in_subsession? is true.

[st0012]

Works great 👍

I think this is one of the changes that requires binstub and rdbgPath to be picked up in time. Can we mention that in the description too?

[st0012]

Oops was meant to approve

[st0012]

@vinistock I think this is a very weird case and we probably need to revisit the implementation later. But for now it's working in our testings and we have a basic test case for it too. So I'll merge this once the build runs green and then test it in Core.

[vinistock]

Some questions for my own learning:

1. What does add_preset_commands do exactly? Is it running the commands?
2. What is kick: false?
3. What is continue: false?

[st0012]

@vinistock Thank you so much for the questions! After taking a closer look, I found that we can probably handle the case even cleaner (see #8). Let me know if the explanation in its description makes sense.

[vinistock]

Does the description go over these specific questions?

[st0012]

Ah sorry it only touches 1) but not the rest.

1. It stores the commands to the Session's preset_command state, but the execution timing of that command depends on Session#wait_command's execution state:
   • If wait_command has reached @ui.readline, then the added preset command will be picked up when the next wait_command_loop iteration. For example, after Session receives another command. This is the most likely scenario.
   • In rare cases, if the preset command is added at the same time wait_command is called, theoretically it'll be executed right away.
2. When kick: true, it'll trigger the current thread client's on_init event, which will go back to make the session enter a subsession. However, I don't know its exact purpose.
3. continue: controls if the debugger should continue the program when all preset commands are finished. For example, debugger(do: "bt") would set continue: true and the program would continue after bt is executed. But debugger(pre: "bt") would set continue: false and the program would remain suspended after bt is executed.

[vinistock]

Thank you so much for the explanations!