From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21304 invoked by alias); 24 Jun 2004 18:25:26 -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 21264 invoked from network); 24 Jun 2004 18:25:25 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Jun 2004 18:25:25 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5OIPPe3024945 for ; Thu, 24 Jun 2004 14:25:25 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5OIPP010753; Thu, 24 Jun 2004 14:25:25 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 22AB52B9D; Thu, 24 Jun 2004 14:25:13 -0400 (EDT) Message-ID: <40DB1C88.1020704@gnu.org> Date: Thu, 24 Jun 2004 18:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: STEP_SKIPS_DELAY question, sort of References: <40AE38D0.7010204@axis.com> <40AE659A.90207@gnu.org> <40B1BD1B.4090300@axis.com> <40B23BB2.6070001@gnu.org> <40B33399.3090803@axis.com> <40B3B742.50007@gnu.org> <40B465E7.7050702@axis.com> <40C45B95.9050309@axis.com> <40C46290.9000402@axis.com> <40C46919.2060802@axis.com> <40C484FE.5080702@gnu.org> <40C6DCF9.2060700@axis.com> <40C73411.9060708@gnu.org> <40CD94F2.8050901@axis.com> <40D05EE4.40601@axis.com> In-Reply-To: <40D05EE4.40601@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00516.txt.bz2 > Orjan Friberg wrote: > >> Andrew Cagney wrote: >> >>> >>> I also think this needs a new macro name that better reflects what the test is doing. But I've no good ideas :-/ (SINGLE_STEP_THROUGH_DELAY (pc)?) > > > I'm facing a slightly different situation than the MIPS case when implementing SINGLE_STEP_THROUGH_DELAY, because the size of the instruction that the delay slot belongs to may be 2, 4, or 6 bytes. (For MIPS, it seems the size of that instruction is always 4 bytes.) > > So, I have to find out the size of the preceding instruction (since I want to do the single-step thingy when we're stopped in the delay slot), but I can't find anything in the opcodes directory that would let me do that. > > The thing is, this information (whether I'm in a delay slot, and the address of the instruction the delay slot belongs to) is available in a register. Besides the fact that this triggers sending a 'g' packet to the remote target, is it wrong to deduce this information from the registers content rather than reading from the program's text segment? > > Basically, my implementation would look like this: > > int > cris_single_step_through_delay (CORE_ADDR pc) > { > ULONGEST erp; > int ret = 0; > regcache_cooked_read_unsigned (current_regcache, ERP_REGNUM, &erp); > if (erp & 0x1) > /* In delay slot - check if there's a breakpoint at the preceding > instruction. */ > if (breakpoint_here_p (erp & ~0x1)) > ret = 1; > return ret; > } Ah! (sorry for the delay). Sounds like a "struct frame_info *this_frame" is the parameter you need then. This will let it work for any frame (especially a frame interrupted by a signal handler). Andrew