From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6061 invoked by alias); 29 Jun 2011 11:21:15 -0000 Received: (qmail 6050 invoked by uid 22791); 29 Jun 2011 11:21:13 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Jun 2011 11:20:59 +0000 Received: by vxg38 with SMTP id 38so1044580vxg.0 for ; Wed, 29 Jun 2011 04:20:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.45.211 with SMTP id g19mr216347vcf.271.1309346458765; Wed, 29 Jun 2011 04:20:58 -0700 (PDT) Received: by 10.220.32.5 with HTTP; Wed, 29 Jun 2011 04:20:58 -0700 (PDT) In-Reply-To: <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> <20110629090941.GD10623@e102109-lin.cambridge.arm.com> Date: Wed, 29 Jun 2011 11:21:00 -0000 Message-ID: Subject: Re: Problem with GDB when debugging IRQ handlers From: Dmitry Eremin-Solenikov To: Catalin Marinas Cc: Russell King - ARM Linux , Yao Qi , Eric Miao , "linux-arm-kernel@lists.infradead.org" , "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 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/msg00173.txt.bz2 On 6/29/11, Catalin Marinas wrote: > 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=0 >> >> 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. >> >> 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. Yes, that actually gave me some ideas. Unfortunately entry*.S files are a bit ... uncommon, so there are nearly no 1-1 cases. BTW: It seems x86 has .cfi annotations connected to most if not all assembler commands. I think this is a bit too much, but you got the idea. -- With best wishes Dmitry