BUG: spin gdb: launch Python directly so that breakpoint is caught

[stefanv]

Closes #24121

[ngoldbaum]

It seems gdb has an option to follow fork to child processes. The following patch seems to work and it retains that it uses spin run under the hood:

diff --git a/.spin/cmds.py b/.spin/cmds.py
index 07e0d6b36..12bb1cbcc 100644
--- a/.spin/cmds.py
+++ b/.spin/cmds.py
@@ -148,8 +148,8 @@ def gdb(python_expr):
 
     """
     util.run(
-        ['gdb', '--args', 'python', '-m', 'spin', 'run',
-         'python', '-P', '-c', python_expr],
+        ['gdb', '-ex', 'set follow-fork-mode child', '--args', 'python', '-m', 'spin', 'run',
+         'python', '-c', python_expr],
         replace=True
     )

Fine with the approach in this PR too if you don't think using spin run is meaningful here.

[ngoldbaum]

Also my Python install seems to complain about the -P argument you pass it,

Unknown option: -P
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

[stefanv]

Yeah, -W only available in 3.11, so I can go back to "run", let me check.

[stefanv]

OK, take another look please. I have to manipulate the sys.path a bit on Python <3.11 to make it work.

Another question about interface: will you always want to run Python code snippets, or should the command allow for arbitrary commands?

[ngoldbaum]

For me, I'd want first to check if the argument is a path that exists and then assume that path is a python script, and then don't pass -c in the case, otherwise use -c and assume the argument is a code snippet. I am often debugging longer scripts or have some setup so I can skip breakpoints that would be hit by import numpy as np.

[stefanv]

I think the interface is now a bit more intuitive.
You can specify code with -c like you would for Python, otherwise it handles like gdb.

[ngoldbaum]

I still think it would be nice to have a mode where you just do spin gdb my_script.py and spin handles constructing the appropriate arguments to do gdb --args python my_script.py.

My reason for that is admittedly a little niche: with pyenv I need to do things like gdb --args $(pyenv which python) my_script.py since the python executable in my path is a shim that delegates to the real python executable and gdb needs the real executable. Having a stronger guarantee that the python being executed is the same one executing spin is also nice.

[stefanv]

OK, done.

[ngoldbaum]

Almost there, with the substantive change I suggested spin gdb test.py "just works" on my setup for a script that imports numpy, then calls os.kill() on itself. 🎉

[stefanv]

Let's see!

[ngoldbaum]

Let’s let someone else test with a different setup before we merge

[stefanv]

Perhaps @mattip or @seberg?

[seberg]

Possible follow-ups I noticed:

• Most other commands rebuild I think, it might be nice to keep it consistent.
• spin gdb without anything dosen't do anything useful, it should maybe use python? (spin python --gdb would also make sense to do that)

We could extend the help to give tips about setting break-points and start things (maybe even slash down the developer help on it and just say to check spin gdb --help?)

Anyway, just noting in case this might spread across many projects really. I might follow-up with running lldb the same way if the system is macos.