From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA] breakpoint.c, scanning epilogue if frame chain is invalid
Date: Wed, 03 Sep 2003 09:38:00 -0000 [thread overview]
Message-ID: <20030903093815.GQ1859@cygbert.vinschen.de> (raw)
Hi,
I'd like to propose the following patch to breakpoint.c:
* breakpoint.c (watchpoint_check): Check for pc being in an
epilogue if watchpoint frame couldn't be found.
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.126
diff -u -p -r1.126 breakpoint.c
--- breakpoint.c 9 Aug 2003 14:57:30 -0000 1.126
+++ breakpoint.c 3 Sep 2003 09:14:02 -0000
@@ -2411,7 +2411,7 @@ watchpoint_check (void *p)
Since we can't rely on the values of local variables after the
stack has been destroyed, we are treating the watchpoint in that
state as `not changed' without further checking. */
- if (within_current_scope && fr == get_current_frame ()
+ if ((!within_current_scope || fr == get_current_frame ())
&& gdbarch_in_function_epilogue_p (current_gdbarch, read_pc ()))
return WP_VALUE_NOT_CHANGED;
if (within_current_scope)
While tracking down a FAIL in testsuite/gdb.base/recurse.exp, I found
that the PC was in the epilogue of a function, at a point where the
FP has been messed up so that frame_find_by_id(b->watchpoint_frame)
was unable to find the watchpoint_frame (which would have been the
frame of the same function 4 recursions above). As a result,
"within_current_scope" would have been set to FALSE and the above
code wouldn't call gdbarch_in_function_epilogue_p() even though it
would have recognized that the PC *is* in an epilogue currently and
would have *correctly* returned TRUE.
As a result of this misbehaviour, the to be checked watchpoint would
have been deleted because that's the consequence of not being in the
scope of the watchpoint.
The above patch is basically this: If we couldn't find the watchpoint
frame, at least try to find out if PC is just in an epilogue. If so,
it's probably the cause of failing to find the watchpoint frame so just
leave the watchpoint alone until we're on firmer ground again. Not
calling gdbarch_in_function_epilogue_p() at this point is not exactly
what gdbarch_in_function_epilogue_p() was originally desigend for and
deleting the watchpoint instead is a bit of an overreaction.
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
next reply other threads:[~2003-09-03 9:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-03 9:38 Corinna Vinschen [this message]
2003-09-03 10:27 ` Eli Zaretskii
2003-09-03 11:18 ` Corinna Vinschen
2003-09-04 17:04 ` Eli Zaretskii
2003-09-04 17:21 ` Andrew Cagney
2003-09-04 17:33 ` Corinna Vinschen
2003-09-04 17:25 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030903093815.GQ1859@cygbert.vinschen.de \
--to=vinschen@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox