This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix PR cli/15603
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 18 Jun 2013 16:02:35 +0200
- Subject: Re: [PATCH] Fix PR cli/15603
- References: <1371224682-19919-1-git-send-email-tromey at redhat dot com> <20130617062907 dot GA27122 at host2 dot jankratochvil dot net> <87txkwbj56 dot fsf at fleche dot redhat dot com> <87hagwbg1y dot fsf at fleche dot redhat dot com> <20130618131929 dot GA18264 at host2 dot jankratochvil dot net>
On Tue, 18 Jun 2013 15:19:29 +0200, Jan Kratochvil wrote:
> > +/* Implement the "explains_signal" breakpoint_ops method for
> > + watchpoints. */
> > +
> > +static enum bpstat_signal_value
> > +explains_signal_watchpoint (struct breakpoint *b, enum gdb_signal sig)
> > +{
> > + /* A software watchpoint cannot cause a signal other than
> > + GDB_SIGNAL_TRAP. */
> > + if (b->type == bp_watchpoint && sig != GDB_SIGNAL_TRAP)
> > + return BPSTAT_SIGNAL_NO;
>
> Even hardware watchpoints create only GDB_SIGNAL_TRAP and no other signal,
> don't they? Why to make the check for bp_watchpoint?
Or maybe some non-x86* arch generates non-TRAP signal on hardware watchpoint?
The infrun.c fix-up does not apply to hardware watchpoints as I see.
if (ecs->ws.kind == TARGET_WAITKIND_STOPPED
&& (ecs->ws.value.sig == GDB_SIGNAL_ILL
|| ecs->ws.value.sig == GDB_SIGNAL_SEGV
|| ecs->ws.value.sig == GDB_SIGNAL_EMT))
[...]
if (breakpoint_inserted_here_p (get_regcache_aspace (regcache),
[...]
ecs->ws.value.sig = GDB_SIGNAL_TRAP;
So if you also have such concerns I agree your patch above does not risk a
regression.
>
>
> > +
> > + return BPSTAT_SIGNAL_HIDE;
> > +}
Jan