From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17449 invoked by alias); 28 Nov 2004 17:26:18 -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 17436 invoked from network); 28 Nov 2004 17:26:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 28 Nov 2004 17:26:14 -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 iASHQ9IM019921 for ; Sun, 28 Nov 2004 12:26:09 -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 iASHQ7r09774; Sun, 28 Nov 2004 12:26:07 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 95B81129D8C; Sun, 28 Nov 2004 12:25:17 -0500 (EST) Message-ID: <41AA09F8.4020006@gnu.org> Date: Sun, 28 Nov 2004 17:26: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> In-Reply-To: <20041123174937.GL9148@tausq.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00485.txt.bz2 Randolph Chung wrote: >> i was trying to figure out that piece of commented out code too and why >> it was changed. looked through cvs history but didn't find it. I'm not >> particularly fond of introducing new almost-arch-specific gdbarch >> methods either, but this does seem to be doing slightly different things >> than the existing ones. OTOH this is almost a "cosmetic" feature, so one >> alternative is to drop the INSTRUCTION_NULLIFIED logic completely.... >> >>Perhaps that isn't such a bad idea if it doesn't confuse GDB too much. > > > 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. > > here's an updated patch to multiarch INSTRUCTION_NULLIFIED, with updated > comments and a somewhat cleaner interface. > > comments? ok to check in? I'm still not convinced (it's me and not mark you need to convince here ;-). 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. Andrew