From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-17016-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 5876 invoked by alias); 27 Jan 2004 08:00:04 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 5869 invoked from network); 27 Jan 2004 08:00:03 -0000
Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173)
  by sources.redhat.com with SMTP; 27 Jan 2004 08:00:03 -0000
Received: from [207.232.27.5] (helo=WST0054)
	by monty-python.gnu.org with asmtp (Exim 4.24)
	id 1AlO7u-0003B2-5V; Tue, 27 Jan 2004 02:59:14 -0500
Date: Tue, 27 Jan 2004 08:00:00 -0000
Message-Id: <u8yjtom6g.fsf@elta.co.il>
From: Eli Zaretskii <eliz@elta.co.il>
To: Andrew Cagney <cagney@gnu.org>
CC: kettenis@chello.nl, gdb@sources.redhat.com
In-reply-to: <40153E6D.2050805@gnu.org> (message from Andrew Cagney on Mon, 26
	Jan 2004 11:21:01 -0500)
Subject: Re: [RFC] Non-executable stack on SPARC
Reply-to: Eli Zaretskii <eliz@elta.co.il>
References: <200401252350.i0PNoB1O021806@elgar.kettenis.dyndns.org> <40153E6D.2050805@gnu.org>
X-SW-Source: 2004-01/txt/msg00313.txt.bz2

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