[PATCH v2 1/3] Change how Python architecture and language are handled

[Simon Marchi]

On 2022-01-10 16:51, Tom Tromey via Gdb-patches wrote:
> Currently, gdb's Python layer captures the current architecture and
> language when "entering" Python code.  This has some undesirable
> effects, and so this series changes how this is handled.
> 
> First, there is code like this:
> 
>   gdbpy_enter enter_py (python_gdbarch, python_language);
> 
> This is incorrect, because both of these are NULL when not otherwise
> assigned.  This can cause crashes in some cases -- I've added one to
> the test suite.  (Note that this crasher is just an example, other
> ones along the same lines are possible.)
> 
> Second, when the language is captured in this way, it means that
> Python code cannot affect the current language for its own purposes.
> It's reasonable to want to write code like this:
> 
>     gdb.execute('set language mumble')
>     ... stuff using the current language
>     gdb.execute('set language previous-value')
> 
> However, this won't actually work, because the language is captured on
> entry.  I've added a test to show this as well.
> 
> This patch changes gdb to try to avoid capturing the current values.
> The Python concept of the current gdbarch is only set in those few
> cases where a non-default value is computed or needed; and the
> language is not captured at all -- instead, in the cases where it's
> required, the current language is temporarily changed.

Hi Tom,

Starting with this patch, I get this failure, consistently:

 78 (gdb) print pid^M
 79 $1 = 1915550^M
 80 (gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
 81 Executing on target: kill -9 1915550    (timeout = 300)
 82 builtin_spawn -ignore SIGHUP kill -9 1915550^M
 83 continue^M
 84 Continuing.^M
 85 Couldn't get registers: No such process.^M
 86 (gdb) FAIL: gdb.threads/killed-outside.exp: prompt after first continue

Do you see it?

Simon