From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21437 invoked by alias); 26 Jan 2004 12:42:36 -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 21430 invoked from network); 26 Jan 2004 12:42:35 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 26 Jan 2004 12:42:35 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i0QCgVIY002039; Mon, 26 Jan 2004 13:42:31 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i0QCgVZM026537; Mon, 26 Jan 2004 13:42:31 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i0QCgUoB026534; Mon, 26 Jan 2004 13:42:30 +0100 (CET) Date: Mon, 26 Jan 2004 12:42:00 -0000 Message-Id: <200401261242.i0QCgUoB026534@elgar.kettenis.dyndns.org> From: Mark Kettenis To: eliz@elta.co.il CC: gdb@sources.redhat.com In-reply-to: (message from Eli Zaretskii on 26 Jan 2004 08:52:08 +0200) Subject: Re: [RFC] Non-executable stack on SPARC References: <200401252350.i0PNoB1O021806@elgar.kettenis.dyndns.org> X-SW-Source: 2004-01/txt/msg00301.txt.bz2 Date: 26 Jan 2004 08:52:08 +0200 From: Eli Zaretskii > 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? 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