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