From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29323 invoked by alias); 8 May 2012 15:08:37 -0000 Received: (qmail 29310 invoked by uid 22791); 8 May 2012 15:08:36 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 May 2012 15:08:23 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SRm1U-0004PP-Nr from Maciej_Rozycki@mentor.com ; Tue, 08 May 2012 08:08:20 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 08:08:20 -0700 Received: from [172.30.1.173] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 8 May 2012 16:08:19 +0100 Date: Tue, 08 May 2012 15:08:00 -0000 From: "Maciej W. Rozycki" To: Mark Kettenis CC: Joel Brobecker , Subject: Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method. In-Reply-To: <201205051144.q45Bitv4006357@glazunov.sibelius.xs4all.nl> Message-ID: References: <1336071802-13599-1-git-send-email-brobecker@adacore.com> <1336071802-13599-2-git-send-email-brobecker@adacore.com> <20120503214933.GJ15555@adacore.com> <20120504205818.GT15555@adacore.com> <201205042118.q44LIh3p018153@glazunov.sibelius.xs4all.nl> <201205051144.q45Bitv4006357@glazunov.sibelius.xs4all.nl> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00233.txt.bz2 On Sat, 5 May 2012, Mark Kettenis wrote: > > As per my suggestion I think it makes sense to document any peculiarities > > of this specific implementation here as well (in this case the safety to > > use with non-executable stack). > > The non-executable stack issue really isn't specific to this > implementation though. On OpenBSD the stack is non-executable on all > architectures where it is possible (including through a clever trick > on i386). I haven't tried ON_STACK on all of them, but it works on > all of them. After some thinking I realised that the reliance on signal delivery to work properly to trap non-executable stack may actually be a problem for bare-iron targets. I'd expect TLB exceptions not to be forwarded up the debug stack in a typical JTAG debugging scenario -- it's not obvious how they should be mapped to signals even, the low-level hardware has no way to classify them and not all have to be fatal; in about the most sophisticated scenario (which is not unlikely, I did that many times myself) consider debugging Linux (the kernel) through JTAG. Instead you'll have the joy of running or stepping through the exception handler (from the probe's point of view it's really no different to an ordinary jump; in the hardware stepping mode the processor will just trap at the exception handler's entry point instead of the intended breakpoint location) on the target and your device being debugged may go astray, e.g. panic blinking LEDs or trigger hardware reset. Given that this feature in the MIPS case comes from the SmartMIPS ASE (that as noted earlier has been designed with smart cards in mind) I think such a scenario is actually not unlikely, even though, as I say, I have never had an opportunity to deal with a MIPS processor that had this non-executable stack feature implemented. Maciej