[PATCH/SPARC-branch] Make call dummies on non-executable stack work

[PATCH/SPARC-branch] Make call dummies on non-executable stack work

[Mark Kettenis]

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 thinkthis will get much
exposure on the branch.

Mark

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

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

[Daniel Jacobowitz]

On Wed, Oct 15, 2003 at 09:57:41PM +0200, 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 thinkthis will get much
> exposure on the branch.

It looks good for mainline to me, too.

> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michael Snyder]

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
> 

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

[Kevin Buettner]

On Oct 15,  3:28pm, Michael Snyder wrote:

> 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.
> 
> 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?

I don't think there's any problem for IA-64.  For FR-V, this might
indeed be a gotcha.  Unfortunately, although I've looked at the
FR-V architecture manual, I'm unable to tell if this'd be a problem
or not.

(Sorry for the less than helpful reply...)

Kevin