Re: [RFC] Non-executable stack on SPARC

[Mark Kettenis <kettenis at chello dot nl>]

   Date: Mon, 26 Jan 2004 11:21:01 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > 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 there are two alternatives:

   I thought the original patch was already committed? :-(

Only to the branch.

   > 1. Only check for SIGSEGV if the target in question uses "ON_STACK"
   >    for its call_dummy_location.

   A more robust check would be to confirm that a breakpoint is at that 
   address (naturally ignoring decr pc after break :-).  However, does 
   later code check exactly that - confirming that the breakpoint explains 
   the stop reason?

Yes.

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

   For this, that would be wrong.  The target, in combination with the 
   breakpoint code, determines if a breakpoint leads to a sigsegv.  Ex: 
   breakpoint code uses the target to unmap code segment, the target 
   indicates that a segment isn't executable, ...

You're probably right.  On Solaris, non-executable stacks are optional
for instance.  And on OpenBSD/sparc you'll probably get a
non-executable stack even when emulating Linux.

   > Preferences?
   > 
   > I'd like to get this sorted before 6.1, since OpenBSD/sparc has a
   > non-executable stack, and some people are running SPARC Solaris with a
   > non-executable stack too.

   Assuming that for VLIW gdb replaces the entire instruction bundle with a 
   breakpoint, a breakpoint instruction can only ever generate a sigtrap 
   (et.al.) (if executed) or sigsegv (if not accessible) so provided there 
   is a breakpoint at the PC I don't think there is any possability of 
   confusion (but again ignore decr pc after break :-).

So does this mean you're convinced that we can add SIGSEGV to the list
currently consisting of SIGILL and SIGEMT unconditionally?  I haven't
seen any ill effects on IA-32 and AMD64 (which are decr pc after
break).  I'll happilly check in the origional patch in mainline too.

Mark