From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4142 invoked by alias); 28 Jun 2011 14:42:26 -0000 Received: (qmail 4130 invoked by uid 22791); 28 Jun 2011 14:42:26 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 28 Jun 2011 14:42:11 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 28 Jun 2011 15:42:07 +0100 Received: from e102109-lin.cambridge.arm.com ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jun 2011 15:42:03 +0100 Date: Tue, 28 Jun 2011 14:42:00 -0000 From: Catalin Marinas To: Russell King - ARM Linux Cc: Dmitry Eremin-Solenikov , Yao Qi , Eric Miao , "linux-arm-kernel@lists.infradead.org" , "gdb@sourceware.org" Subject: Re: Problem with GDB when debugging IRQ handlers Message-ID: <20110628144202.GC24904@e102109-lin.cambridge.arm.com> References: <20110627125306.GA30646@doriath.ww600.siemens.net> <20110627132735.GE16103@n2100.arm.linux.org.uk> <4E088DE1.2060809@gmail.com> <4E089AB3.1090801@codesourcery.com> <20110628103946.GC21898@n2100.arm.linux.org.uk> <20110628142045.GC7255@1n450.cable.virginmedia.net> <20110628143014.GD7255@1n450.cable.virginmedia.net> <20110628143758.GF21898@n2100.arm.linux.org.uk> MIME-Version: 1.0 In-Reply-To: <20110628143758.GF21898@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-MC-Unique: 111062815420703801 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00160.txt.bz2 On Tue, Jun 28, 2011 at 03:37:59PM +0100, Russell King - ARM Linux wrote: > On Tue, Jun 28, 2011 at 03:30:14PM +0100, Catalin Marinas wrote: > > Actually since the return address is in S_PC (which maybe gdb assumes it > > would be the saved LR), this is probably not be correct. After SVC > > entry, we have he following structure on the stack: > >=20 > > ORIG_r0 > > CPSR > > <--- assuming this is the Call Frame Address (SP+S_PC+4) > > PC <--- CFA - 4 > > LR <--- don't care > > SP <--- CFA - 12 > > ... >=20 > If I'm reading this correctly, it's not correct. >=20 > parent SP --> parent context stack > [possible empty word] > ORIG_r0 > parent context CPSR > parent context PC > parent context LR > parent context SP > ... > new SP --> R0 >=20 > That empty word may or may not be present if the parent SP is aligned to > a 64-bit boundary. But it shouldn't matter if we tell gdb that the previous SP (parent) is stored in the current stack at CFA - 12. It calculates CFA by adding S_PC+4 to the current SP, in which case the possible empty word doesn't matter. But please note that I don't have any gdb experience, so we need someone else to confirm. --=20 Catalin