This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Catch exception after stepped over watchpoint.
- From: Yao Qi <yao at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Fri, 2 Aug 2013 19:22:54 +0800
- Subject: Re: [RFC] Catch exception after stepped over watchpoint.
- References: <1372404990-26646-1-git-send-email-yao at codesourcery dot com> <51D6DDA6 dot 3080007 at redhat dot com> <51D7C9D6 dot 5050608 at codesourcery dot com> <51F6A40E dot 4060000 at redhat dot com>
[Sorry for the delay. The build server I used was 'under construction'
(hard disk upgrade) in the last several days.]
On 07/30/2013 01:19 AM, Pedro Alves wrote:
"When the inferior hit a watchpoint, GDB gets a stop and steps over the
watchpoint. GDB will remove all the breakpoints, perform single step,
wait, and insert breakpoints again."
OK, but then, the first time around, the first time we try
to install watchpoints, somewhere, we swallow the error and
continue anyway. So the question is, why is the first time
we try to insert too many watchpoints different from
this case? Where is the error swallowing in the first case
handled? Why doesn't_that_ trigger here?
Your question is clear to me now. I thought about this question when I
wrote this patch one month ago. I 'set debug remote 1' to capture the
rsp packets, and find that only *one* watchpoint was installed at the
first time. When program hits the watchpoint, GDB re-installs *two*
hardware watchpoints then, which trigger the exception. However, I
didn't analyze why only one hardware watchpoint is installed.
I re-run gdb.base/watchpoint.exp again today, but unable to reproduce
the internal error on FSF trunk :(. Sorry about the noise.
I'll follow up this issue if I can reproduce it in many runs.
--
Yao (éå)