This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH/SPARC-branch] Make call dummies on non-executable stackwork


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]