From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13915 invoked by alias); 15 Oct 2003 22:28:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13900 invoked from network); 15 Oct 2003 22:28:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Oct 2003 22:28:58 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9FMSvM23803 for ; Wed, 15 Oct 2003 18:28:57 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9FMSoL27926; Wed, 15 Oct 2003 18:28:56 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h9FMSoJ08603; Wed, 15 Oct 2003 15:28:50 -0700 Message-ID: <3F8DCA21.2080000@redhat.com> Date: Wed, 15 Oct 2003 22:28:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sources.redhat.com Subject: Re: [PATCH/SPARC-branch] Make call dummies on non-executable stack work References: <200310151957.h9FJvfwc000383@elgar.kettenis.dyndns.org> In-Reply-To: <200310151957.h9FJvfwc000383@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00514.txt.bz2 Mark Kettenis wrote: > The attached patch makes call dummies on a non-executable stack > working. I checked this in on my SPARC branch. What do people think > about checking this in on mainline? I don't think this will get much > exposure on the branch. > > Mark I guess the only way you would get a false positive here would be if you took a SEGV while executing a breakpoint trap. I *guess* that seems unlikely -- but I wonder if there's a pathological case, or if one might see this happening while porting gdb to a new target, an immature sim, or something? Is there a gotcha, for instance, for VLIW machines? Might execute the trap, and another instruction simultaneously? Kevin? > > Index: ChangeLog > from Mark Kettenis > > * infrun.c (handle_inferior_event): Allow for breakpoint > instructions to generate a SIGSEGV in addition to SIGTRAP, SIGILL > and SIGEMT. Update comments. > > Index: infrun.c > =================================================================== > RCS file: /cvs/src/src/gdb/infrun.c,v > retrieving revision 1.113 > diff -u -p -r1.113 infrun.c > --- infrun.c 14 Sep 2003 16:32:13 -0000 1.113 > +++ infrun.c 15 Oct 2003 19:54:43 -0000 > @@ -1845,16 +1845,21 @@ handle_inferior_event (struct execution_ > will be made according to the signal handling tables. */ > > /* First, distinguish signals caused by the debugger from signals > - that have to do with the program's own actions. > - Note that breakpoint insns may cause SIGTRAP or SIGILL > - or SIGEMT, depending on the operating system version. > - Here we detect when a SIGILL or SIGEMT is really a breakpoint > - and change it to SIGTRAP. */ > + that have to do with the program's own actions. Note that > + breakpoint insns may cause SIGTRAP or SIGILL or SIGEMT, depending > + on the operating system version. Here we detect when a SIGILL or > + SIGEMT is really a breakpoint and change it to SIGTRAP. We do > + something similar for SIGSEGV, since a SIGSEGV will be generated > + when we're trying to execute a breakpoint instruction on a > + non-executable stack. This happens for call dummy breakpoints > + for architectures like SPARC that place call dummies on the > + stack. */ > > if (stop_signal == TARGET_SIGNAL_TRAP > || (breakpoints_inserted && > (stop_signal == TARGET_SIGNAL_ILL > - || stop_signal == TARGET_SIGNAL_EMT)) > + || stop_signal == TARGET_SIGNAL_EMT > + || stop_signal == TARGET_SIGNAL_SEGV)) > || stop_soon == STOP_QUIETLY > || stop_soon == STOP_QUIETLY_NO_SIGSTOP) > { > @@ -1937,10 +1942,14 @@ handle_inferior_event (struct execution_ > > If someone ever tries to get get call dummys on a > non-executable stack to work (where the target would stop > - with something like a SIGSEG), then those tests might need to > - be re-instated. Given, however, that the tests were only > + with something like a SIGSEGV), then those tests might need > + to be re-instated. Given, however, that the tests were only > enabled when momentary breakpoints were not being used, I > - suspect that it won't be the case. */ > + suspect that it won't be the case. > + > + NOTE: kettenis/2003-10-15: Indeed such checks don't seem to > + be necessary for call dummies on a non-executable stack on > + SPARC. */ > > if (stop_signal == TARGET_SIGNAL_TRAP) > ecs->random_signal >