From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15608 invoked by alias); 28 Jun 2011 15:06:54 -0000 Received: (qmail 15600 invoked by uid 22791); 28 Jun 2011 15:06:53 -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 15:06:40 +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 16:06:35 +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 16:06:33 +0100 Date: Tue, 28 Jun 2011 15:06:00 -0000 From: Catalin Marinas To: Dmitry Eremin-Solenikov Cc: Russell King - ARM Linux , Yao Qi , Eric Miao , "linux-arm-kernel@lists.infradead.org" , "gdb@sourceware.org" Subject: Re: Problem with GDB when debugging IRQ handlers Message-ID: <20110628150631.GD24904@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> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-MC-Unique: 111062816063512201 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/msg00163.txt.bz2 On Tue, Jun 28, 2011 at 03:54:11PM +0100, Dmitry Eremin-Solenikov wrote: > On 6/28/11, Dmitry Eremin-Solenikov wrote: > > On 6/28/11, 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: > >> > >> ORIG_r0 > >> CPSR > >> <--- assuming this is the Call Frame Address (SP+S_PC+4) > >> PC <--- CFA - 4 > >> LR <--- don't care > >> SP <--- CFA - 12 > >> ... > >> > >> > >> So we tell gdb about this with something like below (untested): > >> > >> .cfi_def_cfa_offset S_PC + 4 > >> .cfi_offset 14, -4 > >> .cfi_offset 13, -12 > > > > This brings "unknown CFA rule" gdb exception, but it seems I got your i= dea. >=20 > No, this seems to work, it was my fault. I got more or less reasonable > backtrace now. Does gdb manage to get into the parent stack frame? BTW, are you compiling with FRAME_POINTER enabled? In this case you would need to set some offset for the FP register (11). If you don't mind missing the first part in the parent context, maybe something like below: .cfi_def_cfa_offset S_PC .cfi_offset 14, -4 .cfi_offset 13, -8 .cfi_offset 11, -16 --=20 Catalin