From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 798 invoked by alias); 26 Jan 2004 06:51:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 772 invoked from network); 26 Jan 2004 06:51:55 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 26 Jan 2004 06:51:55 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.24) id 1Al0Zs-0004kU-1P; Mon, 26 Jan 2004 01:50:32 -0500 Date: Mon, 26 Jan 2004 06:51:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis CC: gdb@sources.redhat.com In-reply-to: <200401252350.i0PNoB1O021806@elgar.kettenis.dyndns.org> (message from Mark Kettenis on Mon, 26 Jan 2004 00:50:11 +0100 (CET)) Subject: Re: [RFC] Non-executable stack on SPARC Reply-to: Eli Zaretskii References: <200401252350.i0PNoB1O021806@elgar.kettenis.dyndns.org> X-SW-Source: 2004-01/txt/msg00299.txt.bz2 > Date: Mon, 26 Jan 2004 00:50:11 +0100 (CET) > From: 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 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.