From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19820 invoked by alias); 4 Sep 2003 11:45:28 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 19732 invoked from network); 4 Sep 2003 11:45:24 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 4 Sep 2003 11:45:24 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id MAA23375; Thu, 4 Sep 2003 12:44:50 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h84Bio518885; Thu, 4 Sep 2003 12:44:50 +0100 Message-Id: <200309041144.h84Bio518885@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: mckennad@esatclear.ie cc: Richard Earnshaw , gdb@sources.redhat.com, insight@sources.redhat.com, nickc@redhat.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: ARM Simulator Bug? In-reply-to: Your message of "Wed, 03 Sep 2003 16:19:48 BST." <200309031519.h83FJmX18357@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Sep 2003 11:45:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-q3/txt/msg00145.txt.bz2 Ok, the executive summary on this is that gdb seems to have done the right thing (inserted a Thumb breakpoint at the appropriate point), but the simulator is ignoring this by treating it as a nop. That's not very helpful, especially since it's then "nop"ped out a real instruction. The reason that the behaviour changes when you drop in your link script is that it causes a SWI vector to be installed (at least, it does according to the primitive logic in the simulator), and hence SWI_vector_installed becomes true. What happens is that the Thumb decoder translates the instruction into an ARM BKPT instruction, and it then runs the following ARM code to handle that: if (state->is_v5) { if (BITS (4, 7) == 0x7) { ARMword value; extern int SWI_vector_installed; /* Hardware is allowed to optionally override this instruction and treat it as a breakpoint. Since this is a simulator not hardware, we take the position that if a SWI vector was not installed, then an Abort vector was probably not installed either, and so normally this instruction would be ignored, even if an Abort is generated. This is a bad thing, since GDB uses this instruction for its breakpoints (at least in Thumb mode it does). So intercept the instruction here and generate a breakpoint SWI instead. */ if (! SWI_vector_installed) ARMul_OSHandleSWI (state, SWI_Breakpoint); else { /* BKPT - normally this will cause an abort, but on the XScale we must check the DCSR. */ XScale_set_fsr_far (state, ARMul_CP15_R5_MMU_EXCPT, pc); if (!XScale_debug_moe (state, ARMul_CP14_R10_MOE_BT)) break; } /* Force the next instruction to be refetched. */ state->NextInstr = RESUME; break; Now, since SWI_vector_installed is true, we don't call ARMul_OSHandleSWI for this case, so the debugger never gets re-entered (normally done through SWI_Breakpoint). I think the code should call ARMul_UndefInstr() if there isn't a specific handler for it. The argument that if there isn't a SWI handler then there won't be an abort handler seems specious -- it's not an abort anyway. This is all a mess. But I'm not sure right now how best to start untangling it. R.