Re: [RFC] Non-executable stack on SPARC

[Mark Kettenis <kettenis at chello dot nl>]

   Date: 26 Jan 2004 08:52:08 +0200
   From: Eli Zaretskii <eliz@elta.co.il>

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

Yup, it's the one.  And I agree that there is a risk, and therefore I
don't want to treat SIGSEGV that way on all targets.  With my patch,
or with the suggestions I made below, GDB will usually still see
SIGSEG under normal circumstances.  GDB will only convert such a
signal into SIGTRAP if there's a breakpoint inserted at the point
where the inferior stopped.  The question is what happens when somehow
the program generates a SIGSEGV at a location very close to the point
where we've inserted a breakpoint.  Michael suggested that my patch
would do the wrong thing if the SIGSEGV generating instruction and the
breakpoint instruction are contained within the same instruction
bundle on a VLIW machine.  There might be problems on machines with
some sort of deferred trap mechanism too.

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

Let me clarify 2) first.  My only intention is that the
breakpoint_signal_p() method would return non-zero for all signals
that could be caused by hitting a breakpoint, i.e. SIGILL and SIGEMT
by default, and SIGILL, SIGEMT and SIGSEGV for the particular case of
SPARC.

As to punting the SIGSEGV to SIGTRAP conversion to the architecture:
we could do this in target_wait() or target_wait_hook(), but that
would offload it to the target we're running on and not to the
architecture.

Mark