From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23562 invoked by alias); 28 Jun 2011 10:40:22 -0000 Received: (qmail 23553 invoked by uid 22791); 28 Jun 2011 10:40:21 -0000 X-SWARE-Spam-Status: No, hits=1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SARE_BAYES_5x8,SARE_BAYES_6x8,SARE_BAYES_7x8,TW_BF,TW_CF,TW_PX,TW_SN,TW_ZC,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from caramon.arm.linux.org.uk (HELO caramon.arm.linux.org.uk) (78.32.30.218) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jun 2011 10:40:04 +0000 Received: from n2100.arm.linux.org.uk ([2002:4e20:1eda:1:214:fdff:fe10:4f86]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QbVhs-0002ov-Ua; Tue, 28 Jun 2011 11:39:49 +0100 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.72) (envelope-from ) id 1QbVhr-0006KJ-Bx; Tue, 28 Jun 2011 11:39:47 +0100 Date: Tue, 28 Jun 2011 10:40:00 -0000 From: Russell King - ARM Linux To: Yao Qi Cc: Dmitry Eremin-Solenikov , gdb@sourceware.org, linux-arm-kernel@lists.infradead.org, Eric Miao Subject: Re: Problem with GDB when debugging IRQ handlers Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E089AB3.1090801@codesourcery.com> User-Agent: Mutt/1.5.19 (2009-01-05) 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/msg00151.txt.bz2 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. This is all the same process - kthread() created PID270 (kswapd0) which is the same process which was present when the interrupt happened.