RE: [PING^2][PATCH 0/6] Fix inferior calls from breakpoint condition

RE: [PING^2][PATCH 0/6] Fix inferior calls from breakpoint condition

[Saiapova, Natalia]

Kind ping for https://sourceware.org/pipermail/gdb-patches/2020-August/171592.html

Regards,
--Natalia

> Hi,
> 
> We have noticed that inferior calls evaluated from a breakpoint condition in a
> multithreaded program result in an assertion hit:
> 
>     (gdb) b 43 if foo()
>     Breakpoint 1 at 0x119b: file main.c, line 43.
>     (gdb) run
>     Starting program: main
>     [Thread debugging using libthread_db enabled]
>     Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>     [New Thread 0x7ffff77c4700 (LWP 21421)]
>     [New Thread 0x7ffff6fc3700 (LWP 21422)]
>     gdb/nat/x86-linux-dregs.c:146: internal-error: void
> x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)'
> failed.
>     A problem internal to GDB has been detected,
>     further debugging may prove unreliable.
> 
>     This is a bug, please report it.  For instructions, see:
>     <https://www.gnu.org/software/gdb/bugs/>.
> 
> This patch set aims to fix this and a few more follow-up issues in order to allow
> execution of an inferior call from a breakpoint condition.
> 
> We have introduced an indicator in_cond_eval in the thread_control_state
> struct.  It is set to true, when the correspoding thread is evaluating a breakpoint
> condition.  Based on its value, GDB can distinguish inferior calls issued by a user
> from inferior calls executed in breakpoint conditions.  As GDB decides whether
> to stop a thread based on the result of a condition, it has to try to not abandon
> such an inferior call and finish the condition evaluation whenever this is possible.
> 
> The patch set is tested on x86_64-pc-linux-gnu configuration, the default and
> gdbserver-native boards.
> 
> Regards,
> --Natalia
> 
> Natalia Saiapova:
> Tankut Baris Aktemur:
>   gdb: add in_cond_eval field to thread_control_state struct.
>   gdb/infrun: in condition evaluation resume only current thread.
>   gdb/infcall: in condition evaluation register target back after infcall.
>   gdb/infrun: in condition evaluation wait only for current inferor.
>   gdb/infrun: in condition evaluation do not stop all threads.
>   gdb/testsuite: add tests for inferior calls in breakpoint conditions.
> 
>  gdb/ChangeLog                                 | 34 +++++++++
>  gdb/breakpoint.c                              |  3 +
>  gdb/gdbthread.h                               |  3 +
>  gdb/infcall.c                                 |  3 +
>  gdb/infrun.c                                  | 35 +++++++--
>  gdb/testsuite/ChangeLog                       |  5 ++
>  gdb/testsuite/gdb.threads/infcall-bp-cond.c   | 58 +++++++++++++++
>  gdb/testsuite/gdb.threads/infcall-bp-cond.exp | 73 +++++++++++++++++++
>  8 files changed, 208 insertions(+), 6 deletions(-)  create mode 100644
> gdb/testsuite/gdb.threads/infcall-bp-cond.c
>  create mode 100644 gdb/testsuite/gdb.threads/infcall-bp-cond.exp
> 
> --
> 2.17.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PING^2][PATCH 0/6] Fix inferior calls from breakpoint condition

[Kevin Buettner]

On Tue, 29 Sep 2020 11:55:26 +0000
"Saiapova, Natalia via Gdb-patches" <gdb-patches@sourceware.org> wrote:

> Kind ping for https://sourceware.org/pipermail/gdb-patches/2020-August/171592.html

Hi Natalia,

I attempted to apply your patches to GDB's current HEAD / master but ran
into problems.

One of the problems is that your commits include diffs for the various
ChangeLog files.  We prefer that you place ChangeLog entries into
the commit log (which you did), but exclude them from the diffs.

Due to churn in the GDB sources, I think there were other reasons
that your patches didn't apply cleanly too.

Could you rebase your patches against current upstream master and
then repost them?

Thanks,

Kevin