[RFC] Non-executable stack on SPARC

[RFC] Non-executable stack on SPARC

[Mark Kettenis]

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:

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

Mark


Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.122
diff -u -p -r1.122 infrun.c
--- infrun.c 25 Nov 2003 16:01:36 -0000 1.122
+++ infrun.c 25 Jan 2004 23:37:01 -0000
@@ -1864,6 +1864,7 @@ handle_inferior_event (struct execution_
   if (stop_signal == TARGET_SIGNAL_TRAP
       || (breakpoints_inserted &&
 	  (stop_signal == TARGET_SIGNAL_ILL
+	   || stop_signal == TARGET_SIGNAL_SEGV
 	   || stop_signal == TARGET_SIGNAL_EMT))
       || stop_soon == STOP_QUIETLY
       || stop_soon == STOP_QUIETLY_NO_SIGSTOP)

Re: [RFC] Non-executable stack on SPARC

[Daniel Jacobowitz]

On Mon, Jan 26, 2004 at 12:50:11AM +0100, Mark Kettenis wrote:
> 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:
> 
> 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 just the patch you included will be OK.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Non-executable stack on SPARC

[Eli Zaretskii]

> Date: Sun, 25 Jan 2004 18:59:13 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> I think just the patch you included will be OK.

Not surprising, since you were happy with it back in October, when
this issue was first raised.

Re: [RFC] Non-executable stack on SPARC

[Eli Zaretskii]

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

Re: [RFC] Non-executable stack on SPARC

[Mark Kettenis]

   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

Re: [RFC] Non-executable stack on SPARC

[Eli Zaretskii]

> Date: Mon, 26 Jan 2004 13:42:30 +0100 (CET)
> From: Mark Kettenis <kettenis@chello.nl>
> 
> 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.

Where is this last condition tested to be true?  The if clause where
you wanted to add SIGSEGV doesn't test that, I think.

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

So perhaps we need an architecture way to do such conversions.

My line of thought is that it's IMHO fundamentally wrong to push
target- or architecture-specific details into the application level of
GDB, which is what infrun.c is.  infrun.c should deal with high-level
logic of handling a stopped inferior, it should not IMHO know about
intricacies of specific targets.

Re: [RFC] Non-executable stack on SPARC

[Mark Kettenis]

   Date: 27 Jan 2004 09:56:52 +0200
   From: Eli Zaretskii <eliz@elta.co.il>

   > Date: Mon, 26 Jan 2004 13:42:30 +0100 (CET)
   > From: Mark Kettenis <kettenis@chello.nl>
   > 
   > 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.

   Where is this last condition tested to be true?  The if clause where
   you wanted to add SIGSEGV doesn't test that, I think.

It's quite a bit further down where this gets resolved; see
infrun.c:1962.  The signal is only converted into SIGTRAP if the
signal can be explained by a breakpoint.

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

   So perhaps we need an architecture way to do such conversions.

   My line of thought is that it's IMHO fundamentally wrong to push
   target- or architecture-specific details into the application level of
   GDB, which is what infrun.c is.  infrun.c should deal with high-level
   logic of handling a stopped inferior, it should not IMHO know about
   intricacies of specific targets.

The question is to what extent this is an intricacy of a specific
target.  All targets that use ON_STACK call dummies and have a
non-executable stack will need this adjustment.  More and more systems
gain non-executable stacks.  Hopefully no other ABI's besides SPARC
will require ON_STACK call dummies, but that's probably wishful
thinking.

Anyway, the SIGSEGV would be handled exactly as we already handle
SIGILL and SIGEMT.  Pushing things off to the target/architecture
vector would involve code duplication that I'd rather avoid.

Mark

Re: [RFC] Non-executable stack on SPARC

[Eli Zaretskii]

> Date: Sun, 1 Feb 2004 18:48:19 +0100 (CET)
> From: Mark Kettenis <kettenis@chello.nl>
> 
>    My line of thought is that it's IMHO fundamentally wrong to push
>    target- or architecture-specific details into the application level of
>    GDB, which is what infrun.c is.  infrun.c should deal with high-level
>    logic of handling a stopped inferior, it should not IMHO know about
>    intricacies of specific targets.
> 
> The question is to what extent this is an intricacy of a specific
> target.

I think that the set of signals, apart of SIGTRAP, that can express a
breakpoint on a given target/architecture is something infrun.c
shouldn't know about.

Re: [RFC] Non-executable stack on SPARC

[Andrew Cagney]

> Date: Sun, 1 Feb 2004 18:48:19 +0100 (CET)
>> From: Mark Kettenis <kettenis@chello.nl>
>> 
>>    My line of thought is that it's IMHO fundamentally wrong to push
>>    target- or architecture-specific details into the application level of
>>    GDB, which is what infrun.c is.  infrun.c should deal with high-level
>>    logic of handling a stopped inferior, it should not IMHO know about
>>    intricacies of specific targets.
>> 
>> The question is to what extent this is an intricacy of a specific
>> target.
> 
> 
> I think that the set of signals, apart of SIGTRAP, that can express a
> breakpoint on a given target/architecture is something infrun.c
> shouldn't know about.

Yes.

Here, though, we don't have the case of a just-executed breakpoint, 
rather we have a not-yet-executed segmentation fault.  To implement VM 
based breakpoints and watchpoints GDB will need to be able to 
differentiate between the two.  Hence, I think making this edge case 
visible in infrun is better.

enjoy,
Andrew

Re: [RFC] Non-executable stack on SPARC

[Andrew Cagney]

> 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

Re: [RFC] Non-executable stack on SPARC

[Eli Zaretskii]

> Date: Mon, 26 Jan 2004 11:21:01 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> A more robust check would be to confirm that a breakpoint is at that 
> address (naturally ignoring decr pc after break :-).

If we can do that, why do we also test the signal that was reported
when the inferior stopped?  What you say sounds like it would be
enough to verify that the place where it stopped has a breakpoint, and
decide right there and then that it stopped because the breakpoint
breaks, no matter what TARGET_SIGNAL_* was reported.

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

I'm not sure I understand: are you saying that this is a target
issue, not an architecture issue?

Re: [RFC] Non-executable stack on SPARC

[Mark Kettenis]

   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

Re: [RFC] Non-executable stack on SPARC

[Andrew Cagney]

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

We've found no evidence to the contrary - if something later breaks we 
can add that to the testsuite.

Andrew