From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29957 invoked by alias); 28 Jun 2011 16:11:54 -0000 Received: (qmail 29949 invoked by uid 22791); 28 Jun 2011 16:11:52 -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 16:11:38 +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 17:11:33 +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 17:11:29 +0100 Date: Tue, 28 Jun 2011 16:11: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: <20110628161127.GG24904@e102109-lin.cambridge.arm.com> References: <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> <20110628150631.GD24904@e102109-lin.cambridge.arm.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-MC-Unique: 111062817113305601 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/msg00165.txt.bz2 On Tue, Jun 28, 2011 at 04:45:52PM +0100, Dmitry Eremin-Solenikov wrote: > Here is a part of gdb log generated using the attached patch: [...] > #11 0xc0033810 in kernel_thread_helper () > #12 0xc0033810 in kernel_thread_helper () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) Maybe you can add something similar to the kernel_thread_helper in arch/arm/kernel/process.c? I'm not sure whether there is something like .cantunwind (as for the kernel unwinding information). > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > index e8d8856..44daf40 100644 > --- a/arch/arm/kernel/entry-armv.S > +++ b/arch/arm/kernel/entry-armv.S > @@ -28,6 +28,7 @@ > #include "entry-header.S" > #include >=20=20 > + .cfi_sections .debug_frame > /* > * Interrupt handling. Preserves r7, r8, r9 > */ > @@ -113,6 +114,7 @@ ENDPROC(__und_invalid) >=20=20 > .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 Catalin