Re: [PATCH v5 0/8] Fix gdb.base/gdb-sigterm.exp failure/error

[Pedro Alves <pedro@palves.net>]

Hi!

On 2023-02-22 11:46 p.m., Kevin Buettner wrote:
> This series fixes the failure in gdb.base/gdb-sigterm.exp when
> running in environments with glibc-2.34 or later.
> 
> It contains only a few changes from the v4 series posted in
> January:
> 
> https://sourceware.org/pipermail/gdb-patches/2023-January/195579.html
> 
> This series drops part 6 from v4, "Call quit_force for
> gdb_exception_forced_quit in safe_execute_command", in favor of
> Pedros's already committed/pushed "Simplify interp::exec / interp_exec
> - let exceptions propagate".
> 
> In his review of the v4 series, Pedro asked for a new function,
> set_force_quit_flag() which sets sync_quit_force_run and also calls
> set_quit_flag().  This is done in v5's part 7, "Introduce
> set_force_quit_flag and change type of sync_quit_force_run".
> 
> This series also makes several other minor changes that Pedro had
> asked for.
> 
> I've added Tested-by tags for Tom de Vries for all parts except
> for the new part 7 mentioned above.
> 
> Pedro has approved parts 1, 2, and 3; I added Approved-by lines
> referencing Pedro to those parts.
> 

Thank you!

> Pedro gave a sort of half-hearted approval for part 4, "Python QUIT
> processing updates".  I haven't marked this commit with an Approved-by
> line yet.  I would, however, like to commit this one as is.  I think
> that implementing Pedro's suggestion of throwing a Python exception
> corresponding to the forced-quit and then calling set_force_quit_flag()
> when returning out of the Python interpreter is doable, but probably
> also somewhat tricky/involved.  Rather than going a few more rounds on
> this series in an attempt to get those details correct, I'd prefer to
> push the Python and Guile portions of the current series and then
> work on a separate series implementing Pedro's suggestion.  The Python
> and Guile portions of this series will cause GDB to exit on receipt of
> a SIGTERM, but might not be safe for future GDB in which Python (or
> Guile) might be called from GDB from very low level code in which
> certain data structures are not in sync.  If this should happen, we
> might run into other problems anyway if those low-level invocations of
> Python from GDB want be able to call arbitrary methods in GDB's Python
> API.  (We would need to make sure that all of GDB's Python API is safe
> to use with out-of-sync data structures.  I think it's possible that
> some case might trigger the same assert which prompted this series.)

Agreed.

> 
> Kevin Buettner (8):
>   Introduce gdb_exception_forced_quit
>   Handle gdb SIGTERM by throwing / catching gdb_exception_force_quit
>   Catch gdb_exception_error instead of gdb_exception (in many places)
>   Python QUIT processing updates
>   Guile QUIT processing updates
>   QUIT processing w/ explicit throw for gdb_exception_forced_quit
>   Introduce set_force_quit_flag and change type of sync_quit_force_run
>   Forced quit cases handled by resetting sync_quit_force_run

For the whole series:

  Approved-By: Pedro Alves <pedro@palves.net>

Pedro Alves