Re: [RFC] Non-executable stack on SPARC

[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? :-(

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

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

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

Andrew