From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14654 invoked by alias); 28 Nov 2004 19:55:44 -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 14628 invoked from network); 28 Nov 2004 19:55:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 28 Nov 2004 19:55:38 -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 iASJtX50019452 for ; Sun, 28 Nov 2004 14:55:33 -0500 Received: from localhost.redhat.com (vpn50-27.rdu.redhat.com [172.16.50.27]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iASJtXr04917; Sun, 28 Nov 2004 14:55:33 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F0B3B129D8C; Sun, 28 Nov 2004 14:54:51 -0500 (EST) Message-ID: <41AA2D08.3030304@gnu.org> Date: Sun, 28 Nov 2004 19:55: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> In-Reply-To: <20041128184141.GG6359@tausq.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00498.txt.bz2 Randolph Chung wrote: >>Is it possible to create a core file with the PC sitting on the >>nullified instruction, and if such a beast is created, how can GDB >>correctly handle it - GDB clearly can't single step the core file. If >>that problem is solved, this method becomes redundant. > > > what do you mean? this fix is in the handling of inferior events, so > it doesn't apply to core files anyway, right? Right. > what case with core files > do you think needs to be correctly handled? The underlying problem that you described: > i did some more investigations.... turns out this is not a cosmetic > piece of code at all :) > > suppose we have a function that ended with a branch-with-nullify-next > instruction back to the caller. if you did a "step" on the branch, and > we don't skip the nullified instruction, we would end up on the > nullified instruction which actually belongs to the next function. > > for example: > > Dump of assembler code for function call_with_trampolines: > 0x0001217c : copy r3,r1 > 0x00012180 : copy sp,r3 > 0x00012184 : stw,ma r1,40(,sp) > 0x00012188 : ldi -28,r19 > 0x0001218c : fstd fr5,r19(,r3) > 0x00012190 : ldi -28,r19 > 0x00012194 : fldd r19(,r3),fr22 > 0x00012198 : fcpy,dbl fr22,fr4 > 0x0001219c : ldo 40(r3),sp > 0x000121a0 : ldw,mb -40(,sp),r3 > 0x000121a4 : bv,n r0(rp) > End of assembler dump. > (gdb) disassemble 0x121a8 > Dump of assembler code for function marker_indirect_call: > 0x000121a8 : copy r3,r1 > 0x000121ac : copy sp,r3 > 0x000121b0 : stw,ma r1,40(,sp) > 0x000121b4 : ldo 40(r3),sp > 0x000121b8 : ldw,mb -40(,sp),r3 > 0x000121bc : bv,n r0(rp) > > if we are at 0x121a4, and we do a step, it will stop at > "marker_indirect_call" instead of back at the caller of > "call_with_trampolines". since the insn at 0x121a8 is not actually > executed in this call sequence, the correct thing to do is to blindly > step past the nullified instruction before we make any decision on what > to do. If, when resuming the inferior, a double step is required, single_step_through_delay will do the job. 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. It might also be useful to check the SPARC. It has PC/NPC, delay slots, and instruction nullification, so I'd expect similar problems. Andrew