* [Bug gdb/29868] [gdb, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
@ 2022-12-10 11:25 ` vries at gcc dot gnu.org
2022-12-12 3:14 ` [Bug tdep/29868] [gdb/tdep, " vries at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-10 11:25 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[gdb, s390x -m31] |[gdb, s390x]
|breakpoint.c:5784: |breakpoint.c:5784:
|internal-error: |internal-error:
|bpstat_stop_status_nowatch: |bpstat_stop_status_nowatch:
|Assertion |Assertion
|`!target_stopped_by_watchpo |`!target_stopped_by_watchpo
|int ()' |int ()'
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> Well, it's current master and the tentative patch for PR29867, but I expect
> it's unrelated.
Reproduces without that patch, both with and without -m31.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tdep/29868] [gdb/tdep, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
2022-12-10 11:25 ` [Bug gdb/29868] [gdb, s390x] " vries at gcc dot gnu.org
@ 2022-12-12 3:14 ` vries at gcc dot gnu.org
2022-12-12 9:46 ` vries at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-12 3:14 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arnez at linux dot ibm.com,
| |ulrich.weigand at de dot ibm.com
Component|gdb |tdep
Summary|[gdb, s390x] |[gdb/tdep, s390x]
|breakpoint.c:5784: |breakpoint.c:5784:
|internal-error: |internal-error:
|bpstat_stop_status_nowatch: |bpstat_stop_status_nowatch:
|Assertion |Assertion
|`!target_stopped_by_watchpo |`!target_stopped_by_watchpo
|int ()' |int ()'
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
I've added some code for debugging:
...
diff --git a/gdb/s390-linux-nat.c b/gdb/s390-linux-nat.c
index 96833e804e9..654a62545f3 100644
--- a/gdb/s390-linux-nat.c
+++ b/gdb/s390-linux-nat.c
@@ -602,6 +602,9 @@ s390_linux_nat_target::low_forget_process (pid_t pid)
}
}
+static void
+s390_show_debug_regs (int tid, const char *where);
+
/* linux_nat_new_fork hook. */
void
@@ -625,6 +628,12 @@ s390_linux_nat_target::low_new_fork (struct lwp_info
*parent, pid_t child_pid)
child_state->watch_areas = parent_state->watch_areas;
child_state->break_areas = parent_state->break_areas;
+
+ if (show_debug_regs)
+ {
+ s390_show_debug_regs (parent_pid, "fork -- parent");
+ s390_show_debug_regs (child_pid, "fork -- child");
+ }
}
/* Dump PER state. */
@@ -656,6 +665,10 @@ s390_show_debug_regs (int tid, const char *where)
per_info.lowcore.words.perc_atmid,
per_info.lowcore.words.address,
per_info.lowcore.words.access_id);
+
+ int result = (per_info.lowcore.bits.perc_storage_alteration == 1
+ && per_info.lowcore.bits.perc_store_real_address == 0);
+ debug_printf (" stopped_by_watchpoint: %d\n", result);
}
bool
@@ -688,6 +701,8 @@ s390_linux_nat_target::stopped_by_watchpoint ()
memset (&per_lowcore, 0, sizeof (per_lowcore));
if (ptrace (PTRACE_POKEUSR_AREA, s390_inferior_tid (), &parea, 0) < 0)
perror_with_name (_("Couldn't clear watchpoint status"));
+ if (show_debug_regs)
+ s390_show_debug_regs (s390_inferior_tid (), "clear");
}
return result;
...
and then get the following log:
...
$ gdbh -q -batch -ex "set trace-commands on" -x gdb.in
+file
/suse/tdevries/gdb/build/s390x/gdb/testsuite/outputs/gdb.threads/watchpoint-fork/watchpoint-fork-parent-st
+set follow-fork-mode parent
+start
Temporary breakpoint 1 at 0x1000810: file
/suse/tdevries/gdb/src/gdb/testsuite/gdb.threads/watchpoint-fork-st.c, line 49.
Temporary breakpoint 1, main () at
/suse/tdevries/gdb/src/gdb/testsuite/gdb.threads/watchpoint-fork-st.c:49
49 marker ();
+watch var
Hardware watchpoint 2: var
+break marker
Breakpoint 3 at 0x10007da: file
/suse/tdevries/gdb/src/gdb/testsuite/gdb.threads/watchpoint-fork-st.c, line 33.
+info break
Num Type Disp Enb Address What
2 hw watchpoint keep y var
3 breakpoint keep y 0x00000000010007da in marker at
/suse/tdevries/gdb/src/gdb/testsuite/gdb.threads/watchpoint-fork-st.c:33
+maint set show-debug-regs 1
+continue
PER (debug) state for 55488 -- resume
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 40f0 address: 10006a4 PAID: 0
stopped_by_watchpoint: 0
PER (debug) state for 55488 -- stop
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 40f0 address: 10006a4 PAID: 0
stopped_by_watchpoint: 0
Breakpoint 3, marker () at
/suse/tdevries/gdb/src/gdb/testsuite/gdb.threads/watchpoint-fork-st.c:33
33 }
+continue
PER (debug) state for 55488 -- resume
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 40f0 address: 10006a4 PAID: 0
stopped_by_watchpoint: 0
PER (debug) state for 55488 -- stop
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 40f0 address: 10006a4 PAID: 0
stopped_by_watchpoint: 0
PER (debug) state for 55488 -- stop
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 40f0 address: 10006a4 PAID: 0
stopped_by_watchpoint: 0
PER (debug) state for 55488 -- stop
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 20f0 address: 1000820 PAID: 0
stopped_by_watchpoint: 1
PER (debug) state for 55488 -- clear
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 20f0 address: 1000820 PAID: 0
stopped_by_watchpoint: 1
Hardware watchpoint 2: var
Old value = 0
New value = 1
main () at
/suse/tdevries/gdb/src/gdb/testsuite/gdb.threads/watchpoint-fork-st.c:52
52 forkoff (1);
+continue
PER (debug) state for 55488 -- resume
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 20f0 address: 1000820 PAID: 0
stopped_by_watchpoint: 1
PER (debug) state for 55488 -- fork -- parent
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 20f0 address: 1000820 PAID: 0
stopped_by_watchpoint: 1
PER (debug) state for 55490 -- fork -- child
cr9-11: 0 0 0
start, end: 0 0
code/ATMID: 0 address: 0 PAID: 0
stopped_by_watchpoint: 0
PER (debug) state for 55488 -- stop
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 20f0 address: 1000820 PAID: 0
stopped_by_watchpoint: 1
PER (debug) state for 55488 -- clear
cr9-11: 20200000 100203c 100203f
start, end: 100203c 100203f
code/ATMID: 20f0 address: 1000820 PAID: 0
stopped_by_watchpoint: 1
/suse/tdevries/gdb/src/gdb/breakpoint.c:5784: internal-error:
bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
failed.
...
So, the watchpoint triggers, and we try to clear the watch point status in
s390_linux_nat_target::stopped_by_watchpoint to make sure that we "Do not
report this watchpoint again". That doesn't seem to have any effect though,
and when we stop for the fork s390_linux_nat_target::stopped_by_watchpoint
still returns true, causing the assert.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tdep/29868] [gdb/tdep, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
2022-12-10 11:25 ` [Bug gdb/29868] [gdb, s390x] " vries at gcc dot gnu.org
2022-12-12 3:14 ` [Bug tdep/29868] [gdb/tdep, " vries at gcc dot gnu.org
@ 2022-12-12 9:46 ` vries at gcc dot gnu.org
2022-12-12 9:48 ` vries at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-12 9:46 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> we try to clear the watch point status in
> s390_linux_nat_target::stopped_by_watchpoint to make sure that we "Do not
> report this watchpoint again". That doesn't seem to have any effect though,
And that seems to be documented behaviour, in ./arch/s390/kernel/ptrace.c, in
__poke_user_per we have:
...
/*
* There are only three fields in the per_info struct that the
* debugger user can write to.
* 1) cr9: the debugger wants to set a new PER event mask
* 2) starting_addr: the debugger wants to set a new starting
* address to use with the PER event mask.
* 3) ending_addr: the debugger wants to set a new ending
* address to use with the PER event mask.
* The user specified PER event mask and the start and end
* addresses are used only if single stepping is not in effect.
* Writes to any other field in per_info are ignored.
*/
...
So, the bits that we're trying to clear here in per_struct.lowcore, after the
fields listed above.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tdep/29868] [gdb/tdep, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
` (2 preceding siblings ...)
2022-12-12 9:46 ` vries at gcc dot gnu.org
@ 2022-12-12 9:48 ` vries at gcc dot gnu.org
2022-12-12 12:08 ` vries at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-12 9:48 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
I found this bit of code in aarch64_linux_nat_target::stopped_data_address:
...
diff --git a/gdb/s390-linux-nat.c b/gdb/s390-linux-nat.c
index 96833e804e9..02b797e422f 100644
--- a/gdb/s390-linux-nat.c
+++ b/gdb/s390-linux-nat.c
@@ -673,6 +673,13 @@ s390_linux_nat_target::stopped_by_watchpoint ()
if (state->watch_areas.empty ())
return false;
+ siginfo_t siginfo;
+ if (!linux_nat_get_siginfo (inferior_ptid, &siginfo))
+ return false;
+ if (siginfo.si_signo != SIGTRAP
+ || (siginfo.si_code & 0xffff) != TRAP_HWBKPT)
+ return false;
+
parea.len = sizeof (per_lowcore);
parea.process_addr = (addr_t) & per_lowcore;
parea.kernel_addr = offsetof (struct user_regs_struct, per_info.lowcore);
...
and it fixes the test-case.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tdep/29868] [gdb/tdep, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
` (3 preceding siblings ...)
2022-12-12 9:48 ` vries at gcc dot gnu.org
@ 2022-12-12 12:08 ` vries at gcc dot gnu.org
2022-12-12 13:51 ` uweigand at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-12 12:08 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Also fixes:
...
(gdb) PASS: gdb.base/vfork-follow-parent.exp:
resolution_method=schedule-multiple: print unblock_parent = 1
continue^M
Continuing.^M
Reading symbols from
/suse/tdevries/gdb/build/s390x/gdb/testsuite/outputs/gdb.base/vfork-follow-parent/vfork-follow-parent...^M
^M
^M
Fatal signal: Segmentation fault^M
...
ERROR: GDB process no longer exists
GDB process exited with wait status 248659 exp19 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
UNRESOLVED: gdb.base/vfork-follow-parent.exp:
resolution_method=schedule-multiple: continue to break_parent
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tdep/29868] [gdb/tdep, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
` (4 preceding siblings ...)
2022-12-12 12:08 ` vries at gcc dot gnu.org
@ 2022-12-12 13:51 ` uweigand at gcc dot gnu.org
2022-12-12 15:08 ` vries at gcc dot gnu.org
2023-01-11 9:26 ` vries at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: uweigand at gcc dot gnu.org @ 2022-12-12 13:51 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
Ulrich Weigand <uweigand at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uweigand at gcc dot gnu.org
--- Comment #6 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
Thanks for the investigation!
The GDB code to "Do not report this watchpoint again" was added back in 2007 as
part of this patch series:
https://sourceware.org/pipermail/gdb-patches/2007-September/052502.html
https://sourceware.org/pipermail/gdb-patches/2007-September/052503.html
and back then, it probably worked as expected.
The kernel ptrace implementation was changed to prohibit modifying those bits
only in 2011 as part of some generic cleanup and tightening of access rules.
At that point, we probably missed that it broke GDB.
I agree that the TRAP_HWBKPT check looks correct - several other platforms have
an equivalent check, so I think the patch is fine. (Longer term, I'm wondering
if this check shouldn't move to Linux generic code then?)
However, I think we should then *also* remove the "Do not report this
watchpoint again" ptrace call - no sense in having this in if it doesn't work
anyway; it just wastes time and confuses anyone reading that code.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tdep/29868] [gdb/tdep, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
` (5 preceding siblings ...)
2022-12-12 13:51 ` uweigand at gcc dot gnu.org
@ 2022-12-12 15:08 ` vries at gcc dot gnu.org
2023-01-11 9:26 ` vries at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-12 15:08 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #6)
> Thanks for the investigation!
>
Np :)
> The GDB code to "Do not report this watchpoint again" was added back in 2007
> as part of this patch series:
> https://sourceware.org/pipermail/gdb-patches/2007-September/052502.html
> https://sourceware.org/pipermail/gdb-patches/2007-September/052503.html
> and back then, it probably worked as expected.
>
> The kernel ptrace implementation was changed to prohibit modifying those
> bits only in 2011 as part of some generic cleanup and tightening of access
> rules. At that point, we probably missed that it broke GDB.
>
Ack.
> I agree that the TRAP_HWBKPT check looks correct - several other platforms
> have an equivalent check, so I think the patch is fine. (Longer term, I'm
> wondering if this check shouldn't move to Linux generic code then?)
>
> However, I think we should then *also* remove the "Do not report this
> watchpoint again" ptrace call - no sense in having this in if it doesn't
> work anyway; it just wastes time and confuses anyone reading that code.
I've submitted a patch implementing that approach at
https://sourceware.org/pipermail/gdb-patches/2022-December/194635.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tdep/29868] [gdb/tdep, s390x] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()'
2022-12-10 8:18 [Bug gdb/29868] New: [gdb, s390x -m31] breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: Assertion `!target_stopped_by_watchpoint ()' vries at gcc dot gnu.org
` (6 preceding siblings ...)
2022-12-12 15:08 ` vries at gcc dot gnu.org
@ 2023-01-11 9:26 ` vries at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2023-01-11 9:26 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29868
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.1
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ea6929aaac370daddf0999faa553231c8b806b20
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread