From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12202 invoked by alias); 28 Jun 2011 12:07:24 -0000 Received: (qmail 12177 invoked by uid 22791); 28 Jun 2011 12:07:22 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SARE_BAYES_5x8,SARE_BAYES_6x8,SARE_BAYES_7x8,TW_BF,TW_CF,TW_PX,TW_SN,TW_ZC X-Spam-Check-By: sourceware.org Received: from mail-fx0-f54.google.com (HELO mail-fx0-f54.google.com) (209.85.161.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jun 2011 12:07:08 +0000 Received: by fxe4 with SMTP id 4so153110fxe.13 for ; Tue, 28 Jun 2011 05:07:07 -0700 (PDT) Received: by 10.223.62.194 with SMTP id y2mr1333795fah.123.1309262827158; Tue, 28 Jun 2011 05:07:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.29.155 with HTTP; Tue, 28 Jun 2011 05:06:27 -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> From: Hui Zhu Date: Tue, 28 Jun 2011 12:07:00 -0000 Message-ID: Subject: Re: Problem with GDB when debugging IRQ handlers To: Russell King - ARM Linux Cc: Yao Qi , Dmitry Eremin-Solenikov , gdb@sourceware.org, linux-arm-kernel@lists.infradead.org, Eric Miao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00153.txt.bz2 If this kernel didn't open FRAME_POINTER, what will happen? On Tue, Jun 28, 2011 at 18:39, 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. =A0It's still the same process. > > Let me give you a recent example. =A0This may be using frame pointers rat= her > than the unwinder, but serves to illustrate what we - as kernel developer= s - > absolutely must have from the kernel: > > Internal error: Oops: 17 [#1] PREEMPT > Modules linked in: uinput g_ether cryptomgr aead arc4 crypto_algapi rt280= 0usb 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 soun= dcore rfcomm pxaficp_ir ircomm_tty ircomm irda ipv6 hidp hid bluetooth rfki= ll crc16 > CPU: 0 =A0 =A0Not tainted =A0(3.0.0-rc4+ #5) > PC is at complete+0x28/0x7c > LR is at complete+0x28/0x7c > pc : [] =A0 =A0lr : [] =A0 =A0psr: 80000093 > sp : c3897b68 =A0ip : c3897b68 =A0fp : c3897b84 > r10: c4806000 =A0r9 : c381f3e0 =A0r8 : 0000000a > r7 : c30f0da8 =A0r6 : 00000000 =A0r5 : 00000000 =A0r4 : a0000013 > r3 : c3896000 =A0r2 : 00000000 =A0r1 : 00000103 =A0r0 : 00000004 > Flags: Nzcv =A0IRQs off =A0FIQs on =A0Mode SVC_32 =A0ISA ARM =A0Segment k= ernel > Control: 0000397f =A0Table: a080c000 =A0DAC: 00000017 > Process kswapd0 (pid: 270, stack limit =3D 0xc3896278) > [] (complete+0x28/0x7c) from [] (spi_complete+0x10/0x= 14) > [] (spi_complete+0x10/0x14) from [] (giveback+0x114/0= x12c) > [] (giveback+0x114/0x12c) from [] (pump_transfers+0x1= 3c/0x6f8) > [] (pump_transfers+0x13c/0x6f8) from [] (tasklet_acti= on+0x90/0xf0) > [] (tasklet_action+0x90/0xf0) from [] (__do_softirq+0= x98/0x138) > [] (__do_softirq+0x98/0x138) from [] (irq_exit+0x4c/0= xa8) > [] (irq_exit+0x4c/0xa8) from [] (asm_do_IRQ+0x6c/0x8c) > [] (asm_do_IRQ+0x6c/0x8c) from [] (__irq_svc+0x44/0xc= c) > Exception stack(0xc3897c78 to 0xc3897cc0) > 7c60: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4022d320 4022e000 > 7c80: 08000075 00001000 c32273c0 c03ce1c0 c2b49b78 4022d000 c2b420b4 0000= 0001 > 7ca0: 00000000 c3897cfc 00000000 c3897cc0 c00afc54 c002edd8 00000013 ffff= ffff > [] (__irq_svc+0x44/0xcc) from [] (xscale_flush_user_c= ache_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_unm= ap+0x40/0x60) > [] (try_to_unmap+0x40/0x60) from [] (shrink_page_list= +0x2a8/0x8cc) > [] (shrink_page_list+0x2a8/0x8cc) from [] (shrink_ina= ctive_list+0x218/0x344) > [] (shrink_inactive_list+0x218/0x344) from [] (shrink= _zone+0x384/0x4ac) > [] (shrink_zone+0x384/0x4ac) from [] (kswapd+0x490/0x= 7d0) > [] (kswapd+0x490/0x7d0) from [] (kthread+0x90/0x98) > [] (kthread+0x90/0x98) from [] (kernel_thread_exit+0x= 0/0x8) > Code: e3843080 e121f003 e3a00001 ebfff96a (e5953000) > > This shows that we've unwound from 'complete' to '__irq_svc'. =A0That > 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). =A0So 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. >