[RFC] Non-executable stack on SPARC

[Eli Zaretskii]

> Date: Mon, 26 Jan 2004 00:50:11 +0100 (CET)
> From: Mark Kettenis <kettenis@chello.nl>
> 
> A while ago, I established that getting inferior function calls on
> SPARC working with a non-executable stack is remarkably simple.  Just
> acknowledging that breakpoint instructions may cause SIGSEGV, as per
> the attached patch, is enough.  However, some people were afraid that
> blindly applying this patch might cause some problems on other
> targets.

I think I've located the past discussion you refer to here:

  http://sources.redhat.com/ml/gdb-patches/2003-10/msg00500.html

If that's the one, and there was no other discussions except the
thread started by the above message, then I must agree with the fears
that blindly accepting SIGSEGV as a sign of a breakpoint might not be
a good idea for all targets.  Perhaps I'm missing something, but one
scenario that frightens me is that the inferior function causes a real
SIGSEGV--how will GDB handle that with your patch applied?  (Sorry, I
cannot test this myself where I'm typing this.)  For that matter,
what's to prevent a ``normal'' SIGSEGV, due to a bug in the inferior's
normal thread of execution, from passing this test and being treated
as a breakpoint during inferior function being run by GDB?

> I think there are two alternatives:
> 
> 1. Only check for SIGSEGV if the target in question uses "ON_STACK"
>    for its call_dummy_location.
> 
> 2. Add a new method to the architecture vector to check whether a
>    particular signal may have been the result of a breakpoint
>    instruction.  Suggested name & signature:
> 
>    int breakpoint_signal_p (struct gdbarch *gdbarch, int signal)
> 
> Preferences?

I think 2) might be hard on some targets, so I like 1) better.  But
I'd like to see if there's a better alternative, like if an affected
target would convert SIGSEGV to SIGTRAP in this case, so we don't need
to involve the application level of GDB.