From patchwork Tue Jun 28 12:06:11 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Baryshkov X-Patchwork-Id: 924432 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p5SC6jFq016713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jun 2011 12:07:06 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QbX3m-00072j-8b; Tue, 28 Jun 2011 12:06:30 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QbX3l-0007tS-Su; Tue, 28 Jun 2011 12:06:29 +0000 Received: from mail-vw0-f49.google.com ([209.85.212.49]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QbX3h-0007t6-Nn for linux-arm-kernel@lists.infradead.org; Tue, 28 Jun 2011 12:06:28 +0000 Received: by vws8 with SMTP id 8so97807vws.36 for ; Tue, 28 Jun 2011 05:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8MWV6kEsNj23kj9U4RyTVk3cK/kZxVudeNUKIuQWDFM=; b=LPJBpfaie2rQHFZPlWTuoOqI+9+lV28kGw4tfzExi4K1GXIC/6Eel/AuP/ZKtGRms2 +vEGjv/TH/FaVUb9YuKW8DAc2ok6KnSu67lAjwDipWRCGNii/o7bGE81bn1i08UPw9Dd mG5DTvm1Iqa8TO0c/jORPRE1ZB0GpEtPhSxpM= MIME-Version: 1.0 Received: by 10.52.24.16 with SMTP id q16mr1188237vdf.227.1309262771937; Tue, 28 Jun 2011 05:06:11 -0700 (PDT) Received: by 10.220.32.5 with HTTP; Tue, 28 Jun 2011 05:06:11 -0700 (PDT) In-Reply-To: <20110628103946.GC21898@n2100.arm.linux.org.uk> 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> Date: Tue, 28 Jun 2011 16:06:11 +0400 Message-ID: Subject: Re: Problem with GDB when debugging IRQ handlers From: Dmitry Eremin-Solenikov To: Russell King - ARM Linux X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110628_080626_839443_6122E8E4 X-CRM114-Status: GOOD ( 33.88 ) X-Spam-Score: -0.8 (/) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-0.8 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.212.49 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dbaryshkov[at]gmail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Yao Qi , Eric Miao , linux-arm-kernel@lists.infradead.org, gdb@sourceware.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Tue, 28 Jun 2011 12:07:06 +0000 (UTC) On 6/28/11, Russell King - ARM Linux wrote: > On Mon, Jun 27, 2011 at 10:58:59PM +0800, Yao Qi wrote: >> On 06/27/2011 10:04 PM, Dmitry Eremin-Solenikov wrote: >> > Hello, >> > >> > On 27.06.2011 17:27, Russell King - ARM Linux wrote: >> >> We _really_ _do_ want to unwind through this so that we can see the >> >> parent kernel context information in backtraces - and the fact that >> >> I am not sure GDB is able to unwind stacks across processes (from child >> to parent). > > It's not about unwinding across processes. It's still the same process. > > Let me give you a recent example. This may be using frame pointers rather > than the unwinder, but serves to illustrate what we - as kernel developers - > absolutely must have from the kernel: > > Internal error: Oops: 17 [#1] PREEMPT > Modules linked in: uinput g_ether cryptomgr aead arc4 crypto_algapi > rt2800usb rt2800lib rt2x00usb rt2x00lib mac80211 cfg80211 sg pcmciamtd > mousedev snd_soc_wm8750 snd_soc_pxa2xx_i2s snd_soc_core ohci_hcd usbcore > pxa27x_udc physmap snd_pcm_oss snd_pcm snd_timer snd_page_alloc > snd_mixer_oss snd soundcore rfcomm pxaficp_ir ircomm_tty ircomm irda ipv6 > hidp hid bluetooth rfkill crc16 > CPU: 0 Not tainted (3.0.0-rc4+ #5) > PC is at complete+0x28/0x7c > LR is at complete+0x28/0x7c > pc : [] lr : [] psr: 80000093 > sp : c3897b68 ip : c3897b68 fp : c3897b84 > r10: c4806000 r9 : c381f3e0 r8 : 0000000a > r7 : c30f0da8 r6 : 00000000 r5 : 00000000 r4 : a0000013 > r3 : c3896000 r2 : 00000000 r1 : 00000103 r0 : 00000004 > Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 0000397f Table: a080c000 DAC: 00000017 > Process kswapd0 (pid: 270, stack limit = 0xc3896278) > [] (complete+0x28/0x7c) from [] (spi_complete+0x10/0x14) > [] (spi_complete+0x10/0x14) from [] > (giveback+0x114/0x12c) > [] (giveback+0x114/0x12c) from [] > (pump_transfers+0x13c/0x6f8) > [] (pump_transfers+0x13c/0x6f8) from [] > (tasklet_action+0x90/0xf0) > [] (tasklet_action+0x90/0xf0) from [] > (__do_softirq+0x98/0x138) > [] (__do_softirq+0x98/0x138) from [] > (irq_exit+0x4c/0xa8) > [] (irq_exit+0x4c/0xa8) from [] (asm_do_IRQ+0x6c/0x8c) > [] (asm_do_IRQ+0x6c/0x8c) from [] (__irq_svc+0x44/0xcc) > Exception stack(0xc3897c78 to 0xc3897cc0) > 7c60: 4022d320 > 4022e000 > 7c80: 08000075 00001000 c32273c0 c03ce1c0 c2b49b78 4022d000 c2b420b4 > 00000001 > 7ca0: 00000000 c3897cfc 00000000 c3897cc0 c00afc54 c002edd8 00000013 > ffffffff > [] (__irq_svc+0x44/0xcc) from [] > (xscale_flush_user_cache_range+0x18/0x3c) > [] (xscale_flush_user_cache_range+0x18/0x3c) from [] > (try_to_unmap_file+0x98/0x4ec) > [] (try_to_unmap_file+0x98/0x4ec) from [] > (try_to_unmap+0x40/0x60) > [] (try_to_unmap+0x40/0x60) from [] > (shrink_page_list+0x2a8/0x8cc) > [] (shrink_page_list+0x2a8/0x8cc) from [] > (shrink_inactive_list+0x218/0x344) > [] (shrink_inactive_list+0x218/0x344) from [] > (shrink_zone+0x384/0x4ac) > [] (shrink_zone+0x384/0x4ac) from [] > (kswapd+0x490/0x7d0) > [] (kswapd+0x490/0x7d0) from [] (kthread+0x90/0x98) > [] (kthread+0x90/0x98) from [] > (kernel_thread_exit+0x0/0x8) > Code: e3843080 e121f003 e3a00001 ebfff96a (e5953000) > > This shows that we've unwound from 'complete' to '__irq_svc'. That > may not be the full story though - the problem may relate to where we > were when we were interrupted (or indeed took the data or prefetch > abort). So the unwinding from __irq_svc right back to kthread is > just as important. I did some checks. It seems, the problem isn't related to unwinder. At least it looks like kernel has all necessary unwinding subops. It looks like the problem is really related to the lack of necessary .cfi information. At least when i added .cfi_startproc/.cfi_endproc annotations to entry-armv.S code, gdb stopped decoding backtrace with the "previous frame identical to this frame" error. Unfortunately I don't have enough knowledge to add .cfi annotations to irq handlers. For the reference I'm providing the patch in the attachment. Russell, will you agree to merge at least this partial solution, so that gdb chokes, but doesn't go to indefinite recursion? If you'd agree, I'll submit it with proper headers and sign-off. diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index e8d8856..d77f9d7 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -28,6 +28,7 @@ #include "entry-header.S" #include + .cfi_sections .debug_frame /* * Interrupt handling. Preserves r7, r8, r9 */ @@ -113,6 +114,7 @@ ENDPROC(__und_invalid) .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 @@ -347,6 +349,7 @@ ENDPROC(__pabt_svc) .macro usr_entry UNWIND(.fnstart ) UNWIND(.cantunwind ) @ don't unwind the user space + .cfi_startproc sub sp, sp, #S_FRAME_SIZE ARM( stmib sp, {r1 - r12} ) THUMB( stmia sp, {r0 - r12} ) @@ -427,6 +430,7 @@ __dabt_usr: mov r2, sp adr lr, BSYM(ret_from_exception) b do_DataAbort + .cfi_endproc UNWIND(.fnend ) ENDPROC(__dabt_usr) @@ -454,6 +458,7 @@ __irq_usr: mov why, #0 b ret_to_user + .cfi_endproc UNWIND(.fnend ) ENDPROC(__irq_usr) @@ -496,6 +501,7 @@ __und_usr: #else b __und_usr_unknown #endif + .cfi_endproc UNWIND(.fnend ) ENDPROC(__und_usr) @@ -691,6 +697,7 @@ __pabt_usr: enable_irq @ Enable interrupts mov r2, sp @ regs bl do_PrefetchAbort @ call abort handler + .cfi_endproc UNWIND(.fnend ) /* fall through */ /* @@ -699,9 +706,11 @@ __pabt_usr: ENTRY(ret_from_exception) UNWIND(.fnstart ) UNWIND(.cantunwind ) + .cfi_startproc get_thread_info tsk mov why, #0 b ret_to_user + .cfi_endproc UNWIND(.fnend ) ENDPROC(__pabt_usr) ENDPROC(ret_from_exception) diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S index 051166c..5ed13ae 100644 --- a/arch/arm/kernel/entry-header.S +++ b/arch/arm/kernel/entry-header.S @@ -86,6 +86,7 @@ #else ldmia sp, {r0 - pc}^ @ load r0 - pc, cpsr #endif + .cfi_endproc .endm .macro restore_user_regs, fast = 0, offset = 0