Re: [RFC] Non-executable stack on SPARC

Eli Zaretskii
2004-01-26T06:51:56Z

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