This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH/SPARC-branch] Make call dummies on non-executable stackwork
- From: Michael Snyder <msnyder at redhat dot com>
- To: Mark Kettenis <kettenis at chello dot nl>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 15 Oct 2003 15:28:49 -0700
- Subject: Re: [PATCH/SPARC-branch] Make call dummies on non-executable stackwork
- Organization: Red Hat, Inc.
- References: <200310151957.h9FJvfwc000383@elgar.kettenis.dyndns.org>
Mark Kettenis wrote:
The attached patch makes call dummies on a non-executable stack
working. I checked this in on my SPARC branch. What do people think
about checking this in on mainline? I don't think this will get much
exposure on the branch.
Mark
I guess the only way you would get a false positive here
would be if you took a SEGV while executing a breakpoint trap.
I *guess* that seems unlikely -- but I wonder if there's a
pathological case, or if one might see this happening while
porting gdb to a new target, an immature sim, or something?
Is there a gotcha, for instance, for VLIW machines?
Might execute the trap, and another instruction simultaneously?
Kevin?
Index: ChangeLog
from Mark Kettenis <kettenis@gnu.org>
* infrun.c (handle_inferior_event): Allow for breakpoint
instructions to generate a SIGSEGV in addition to SIGTRAP, SIGILL
and SIGEMT. Update comments.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.113
diff -u -p -r1.113 infrun.c
--- infrun.c 14 Sep 2003 16:32:13 -0000 1.113
+++ infrun.c 15 Oct 2003 19:54:43 -0000
@@ -1845,16 +1845,21 @@ handle_inferior_event (struct execution_
will be made according to the signal handling tables. */
/* First, distinguish signals caused by the debugger from signals
- that have to do with the program's own actions.
- Note that breakpoint insns may cause SIGTRAP or SIGILL
- or SIGEMT, depending on the operating system version.
- Here we detect when a SIGILL or SIGEMT is really a breakpoint
- and change it to SIGTRAP. */
+ that have to do with the program's own actions. Note that
+ breakpoint insns may cause SIGTRAP or SIGILL or SIGEMT, depending
+ on the operating system version. Here we detect when a SIGILL or
+ SIGEMT is really a breakpoint and change it to SIGTRAP. We do
+ something similar for SIGSEGV, since a SIGSEGV will be generated
+ when we're trying to execute a breakpoint instruction on a
+ non-executable stack. This happens for call dummy breakpoints
+ for architectures like SPARC that place call dummies on the
+ stack. */
if (stop_signal == TARGET_SIGNAL_TRAP
|| (breakpoints_inserted &&
(stop_signal == TARGET_SIGNAL_ILL
- || stop_signal == TARGET_SIGNAL_EMT))
+ || stop_signal == TARGET_SIGNAL_EMT
+ || stop_signal == TARGET_SIGNAL_SEGV))
|| stop_soon == STOP_QUIETLY
|| stop_soon == STOP_QUIETLY_NO_SIGSTOP)
{
@@ -1937,10 +1942,14 @@ handle_inferior_event (struct execution_
If someone ever tries to get get call dummys on a
non-executable stack to work (where the target would stop
- with something like a SIGSEG), then those tests might need to
- be re-instated. Given, however, that the tests were only
+ with something like a SIGSEGV), then those tests might need
+ to be re-instated. Given, however, that the tests were only
enabled when momentary breakpoints were not being used, I
- suspect that it won't be the case. */
+ suspect that it won't be the case.
+
+ NOTE: kettenis/2003-10-15: Indeed such checks don't seem to
+ be necessary for call dummies on a non-executable stack on
+ SPARC. */
if (stop_signal == TARGET_SIGNAL_TRAP)
ecs->random_signal