From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12300 invoked by alias); 29 Jun 2011 09:10:09 -0000 Received: (qmail 12283 invoked by uid 22791); 29 Jun 2011 09:10:05 -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; Wed, 29 Jun 2011 09:09:50 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 29 Jun 2011 10:09:46 +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); Wed, 29 Jun 2011 10:09:42 +0100 Date: Wed, 29 Jun 2011 09:10: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: <20110629090941.GD10623@e102109-lin.cambridge.arm.com> References: <20110628103946.GC21898@n2100.arm.linux.org.uk> <20110628142045.GC7255@1n450.cable.virginmedia.net> <20110628143014.GD7255@1n450.cable.virginmedia.net> <20110628150631.GD24904@e102109-lin.cambridge.arm.com> <20110628161127.GG24904@e102109-lin.cambridge.arm.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-MC-Unique: 111062910094602401 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/msg00172.txt.bz2 On Tue, Jun 28, 2011 at 11:26:28PM +0100, Dmitry Eremin-Solenikov wrote: > On 6/28/11, Catalin Marinas wrote: > > On Tue, Jun 28, 2011 at 04:45:52PM +0100, Dmitry Eremin-Solenikov wrote: > >> .macro svc_entry, stack_hole=3D0 > >> UNWIND(.fnstart ) > >> + .cfi_startproc > >> UNWIND(.save {r0 - pc} ) > >> sub sp, sp, #(S_FRAME_SIZE + \stack_hole - 4) > >> #ifdef CONFIG_THUMB2_KERNEL > >> @@ -146,6 +148,24 @@ ENDPROC(__und_invalid) > >> @ r4 - orig_r0 (see pt_regs definition in ptrace.h) > >> @ > >> stmia r5, {r0 - r4} > >> + .cfi_def_cfa_offset S_PC + 4 > >> + .cfi_offset 14, -4 > >> +#define CFI_REG_OFF(r) .cfi_offset r, (r - 16) * 4 > >> + CFI_REG_OFF(13) > >> + CFI_REG_OFF(12) > >> + CFI_REG_OFF(11) > >> + CFI_REG_OFF(10) > >> + CFI_REG_OFF(9) > >> + CFI_REG_OFF(8) > >> + CFI_REG_OFF(7) > >> + CFI_REG_OFF(6) > >> + CFI_REG_OFF(5) > >> + CFI_REG_OFF(4) > >> + CFI_REG_OFF(3) > >> + CFI_REG_OFF(2) > >> + CFI_REG_OFF(1) > >> + CFI_REG_OFF(0) > >> +#undef CFI_REG_OFF > >> .endm > > > > Do we need all the registers in here for gdb stack unwinding? In general > > we would only need LR, SP and FP. >=20 > CFI info isn't only related to stack unwinding. IIUC (I'll have to run > more experiments) these instrutions will help me to get correct > variables/arguments values in the before-exception stack frames. OK, in this case we may need to add some annotations. You could actually generate a .s file from and existing C one (including -g) and see what .cfi directives it generates. --=20 Catalin