[v5,0/8] Fix gdb.base/gdb-sigterm.exp failure/error

  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.

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.)

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

 gdb/ada-lang.c                   |  2 +-
 gdb/breakpoint.c                 |  8 ++++----
 gdb/defs.h                       |  5 ++++-
 gdb/event-top.c                  | 15 ++++++++++++---
 gdb/guile/guile-internal.h       |  5 +++++
 gdb/guile/scm-pretty-print.c     |  5 +++++
 gdb/guile/scm-type.c             |  5 +++++
 gdb/guile/scm-value.c            |  5 +++++
 gdb/i386-linux-tdep.c            |  2 +-
 gdb/inf-loop.c                   |  2 +-
 gdb/infcmd.c                     |  2 +-
 gdb/infrun.c                     |  2 +-
 gdb/jit.c                        |  2 +-
 gdb/linux-fork.c                 | 12 ++++++++++++
 gdb/main.c                       | 12 ++++++++++++
 gdb/mi/mi-cmd-break.c            |  2 +-
 gdb/mi/mi-interp.c               |  2 +-
 gdb/mi/mi-main.c                 |  4 ++++
 gdb/objc-lang.c                  |  2 +-
 gdb/parse.c                      |  2 +-
 gdb/printcmd.c                   |  2 +-
 gdb/python/py-finishbreakpoint.c |  5 +++++
 gdb/python/py-gdb-readline.c     |  4 ++++
 gdb/python/py-symbol.c           |  5 +++++
 gdb/python/py-utils.c            |  3 +++
 gdb/python/py-value.c            |  5 +++++
 gdb/record-btrace.c              |  2 +-
 gdb/record-full.c                |  2 +-
 gdb/remote-fileio.c              | 13 +++++++++----
 gdb/solib.c                      |  2 +-
 gdb/sparc64-linux-tdep.c         |  2 +-
 gdb/symfile-mem.c                |  2 +-
 gdb/top.h                        |  2 +-
 gdb/tui/tui-io.c                 |  8 ++++++++
 gdb/tui/tui.c                    |  7 +++++++
 gdb/utils.c                      |  4 ++--
 gdbsupport/common-exceptions.cc  | 14 ++++++++++++++
 gdbsupport/common-exceptions.h   | 22 +++++++++++++++++++++-
 38 files changed, 168 insertions(+), 32 deletions(-)
  

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
  

On Thu, 23 Feb 2023 13:01:07 +0000
Pedro Alves <pedro@palves.net> wrote:

> > 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>

I've pushed this series.  Thanks for all of the reviews!

Kevin