Re: [RFC] Non-executable stack on SPARC

Andrew Cagney
2004-01-26T16:21:05Z

> 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