From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28766 invoked by alias); 29 Nov 2004 15:12:31 -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 28647 invoked from network); 29 Nov 2004 15:12:26 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Nov 2004 15:12:26 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iATFCKYK025939 for ; Mon, 29 Nov 2004 10:12:21 -0500 Received: from localhost.redhat.com (vpn50-72.rdu.redhat.com [172.16.50.72]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iATFCFr07075; Mon, 29 Nov 2004 10:12:15 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 71D54129D8C; Mon, 29 Nov 2004 10:11:28 -0500 (EST) Message-ID: <41AB3C1D.80509@gnu.org> Date: Mon, 29 Nov 2004 15:12:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED References: <20041118000159.GG15714@tausq.org> <419CB118.7080401@gnu.org> <20041118162108.GK15714@tausq.org> <200411181655.iAIGthDa026050@juw15.nfra.nl> <20041123174937.GL9148@tausq.org> <41AA09F8.4020006@gnu.org> <20041128184141.GG6359@tausq.org> <41AA2D08.3030304@gnu.org> <20041129033013.GJ6359@tausq.org> In-Reply-To: <20041129033013.GJ6359@tausq.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00517.txt.bz2 Randolph Chung wrote: >>If, when resuming the inferior, a double step is required, >>single_step_through_delay will do the job. > > > this is not possible to do in the general case though, because, sitting > on the current insn at pc, you cannot necessarily determine if the > next insn will be nullified or not. (in the current example, the > nullification is always applied, but it can be conditional on some > computation being done) I'm not sure what you mean. What you describe sounds like the old STEP_SKIPS_DELAY logic - a test on the _next_ instruction. The new logic instead: # Return non-zero if the processor is executing a delay slot and a # further single-step is needed before the instruction finishes. M::int:single_step_through_delay:struct frame_info *frame:frame checks to see if the _last_ instruction put us into a delay slot. (The MIPS code, which is technically implementing STEP_SKIPS_DELAY, works because when in a delay slot the PC still points at the branch instruction. A fixme would be to change the mips code to instead test the delay-slot bit.). >>However, that doesn't solve the case of GDB encountering a frame >>(inferior) that, be it through attach, cntrl-c, a signal, or a core >>file, is already sitting on the above nullified instruction. The >>corefile case being expecially nasty - trying to get a corefile to step >>off a nullified instruction won't get you very far :-). I suspect that >>the code will need to modify ``pc'' so that it either appears to be one >>instruction behind (the "bv,n") or one instruction ahead (branch >>destination) of what the registers indicate. > > > oh, are you saying that: > if we are looking at a corefile, and the current pc is sitting on a > nullified insn that belonged to the next function, that we may not be > able to do a backtrace correctly? Yes, and more to the point INSTRUCTION_NULLIFIED can't help here. On the other hand, if this case is made to work INSTRUCTION_NULLIFIED is redundant. However, the first question is: can such a corefile be created? Given that GDB can single step an inferior into such a state, I think it can. >>It might also be useful to check the SPARC. It has PC/NPC, delay slots, >>and instruction nullification, so I'd expect similar problems. > > > ok, i'll see if i can find a sparc machine to try to reproduce this > problem there. One thing to check is for isif the SPARC requires padding between functions? -- If you want, add a DEPRECATED_INSTRUCTION_NULLIFIED to the architecture vector and have the PA-RISC use that. While a sideways step, it lets you advance what I'm assuming is the more immediate objective of cleaning out PA's tm*.h files and making it pure multi-arch. Andrew