mbox series

[0/6] Refinement of scheduler-locking settings

Message ID 20231229104202.7878-1-natalia.saiapova@intel.com
Headers
Series Refinement of scheduler-locking settings |

Message

Natalia Saiapova Dec. 29, 2023, 10:41 a.m. UTC 
  Hi all,

I want to come back to the topic I raised a few years ago about the
scheduler locking during the inferior calls.

For the history, here are the links to the previous threads:

https://sourceware.org/pipermail/gdb/2019-June/047996.html
https://sourceware.org/pipermail/gdb/2019-July/048003.html

> In multithreaded program, when several threads are stopped at a
> breakpoint and
> scheduler-locking mode is not 'on', there might be unexpected thread
> switches
> during an inferior call evaluation. If such thread switching occurs,
> the evaluation of the inferior call is abandoned:
> 
> ~~~
> (gdb) run
> Thread 1 "a.out" hit Breakpoint 2, main._omp_fn.0(void) () at
> multi-omp.cpp:18
> 18                                         std::cout <<
> omp_get_thread_num();
> (gdb) call do_something()
> [Switching to Thread 0x7ffff6327700 (LWP 32498)]
> 
> Thread 3 "a.out" hit Breakpoint 2, main._omp_fn.0(void) () at
> multi-omp.cpp:18
> 18                                         std::cout <<
> omp_get_thread_num();
> The program stopped in another thread while making a function call
> from GDB.
> Evaluation of the expression containing the function
> (do_something()) will be abandoned.
> When the function is done executing, GDB will silently stop.
> ~~~

The problem is that only scheduler-locking "on" can lock the scheduler
for inferior calls, which is quite restrictive for debugging.
A possible solution would be to add a new option, e.g., "eval", to the
existing "set scheduler-locking", but this might often be used
together with the "step" option, so a user would need to always remember
to switch the scheduler-locking to the correct option.

I chose a different and a more invasive direction and prepared a set of patches 
that introduce a finer control over the scheduler locking.  With that, a user
can choose for which types of commands the scheduler should be locked and mix
different locking strategies together.  For the moment, I distinguish two modes
(normal and replay) and three command types (continuing, stepping, and inferior
call evaluation).  This way, we can lock the scheduler during the stepping and
inferior calls, but leave it unlocked for "continue".

I tried to be backwards compatible, so all existing scheduler-locking
settings are expected to be preserved, however, the "show" commands had
to be changed.

I will be happy to hear your opinion on the proposed change to the
scheduler locking interface!

Regards
Natalia

My base commit is 
3bb1944a5a0 asan: buffer overflow in loongarch_elf_rtype_to_howto

Natalia Saiapova (6):
  gdb: use schedlock_applies in user_visible_resume_ptid.
  gdb, cli: remove left-over code from "set_logging_on".
  gdb, cli: pass the argument of a set command to its callback.
  gdb: change the internal representation of scheduler locking.
  gdb: add commands to control scheduler locking.
  gdb: add eval option to lock the scheduler during infcalls.

 gdb/NEWS                                      |  21 +
 gdb/cli/cli-logging.c                         |   5 -
 gdb/cli/cli-setshow.c                         |   2 +-
 gdb/doc/gdb.texinfo                           |  68 ++-
 gdb/infrun.c                                  | 410 +++++++++++++++---
 .../gdb.mi/user-selected-context-sync.exp     |  22 +-
 .../gdb.threads/hand-call-in-threads.exp      |   8 +-
 .../multiple-successive-infcall.exp           |   5 +-
 gdb/testsuite/gdb.threads/schedlock.exp       | 103 ++++-
 gdb/testsuite/lib/gdb.exp                     |  57 ++-
 10 files changed, 580 insertions(+), 121 deletions(-)