From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11265 invoked by alias); 28 Jun 2011 12:06:30 -0000 Received: (qmail 11251 invoked by uid 22791); 28 Jun 2011 12:06:26 -0000 X-SWARE-Spam-Status: No, hits=-0.8 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-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jun 2011 12:06:12 +0000 Received: by vxg38 with SMTP id 38so124579vxg.0 for ; Tue, 28 Jun 2011 05:06:12 -0700 (PDT) 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 12:06:00 -0000 Message-ID: Subject: Re: Problem with GDB when debugging IRQ handlers From: Dmitry Eremin-Solenikov To: Russell King - ARM Linux Cc: Yao Qi , gdb@sourceware.org, linux-arm-kernel@lists.infradead.org, Eric Miao Content-Type: multipart/mixed; boundary=20cf307ac3d370614604a6c47e1e 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/msg00152.txt.bz2 --20cf307ac3d370614604a6c47e1e Content-Type: text/plain; charset=ISO-8859-1 Content-length: 4662 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. -- With best wishes Dmitry --20cf307ac3d370614604a6c47e1e Content-Type: text/x-patch; charset=US-ASCII; name="ARM_CFI.patch" Content-Disposition: attachment; filename="ARM_CFI.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 Content-length: 2689 ZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2tlcm5lbC9lbnRyeS1hcm12LlMgYi9h cmNoL2FybS9rZXJuZWwvZW50cnktYXJtdi5TCmluZGV4IGU4ZDg4NTYuLmQ3 N2Y5ZDcgMTAwNjQ0Ci0tLSBhL2FyY2gvYXJtL2tlcm5lbC9lbnRyeS1hcm12 LlMKKysrIGIvYXJjaC9hcm0va2VybmVsL2VudHJ5LWFybXYuUwpAQCAtMjgs NiArMjgsNyBAQAogI2luY2x1ZGUgImVudHJ5LWhlYWRlci5TIgogI2luY2x1 ZGUgPGFzbS9lbnRyeS1tYWNyby1tdWx0aS5TPgogCisJLmNmaV9zZWN0aW9u cwkuZGVidWdfZnJhbWUKIC8qCiAgKiBJbnRlcnJ1cHQgaGFuZGxpbmcuICBQ cmVzZXJ2ZXMgcjcsIHI4LCByOQogICovCkBAIC0xMTMsNiArMTE0LDcgQEAg RU5EUFJPQyhfX3VuZF9pbnZhbGlkKQogCiAJLm1hY3JvCXN2Y19lbnRyeSwg c3RhY2tfaG9sZT0wCiAgVU5XSU5EKC5mbnN0YXJ0CQkpCisJLmNmaV9zdGFy dHByb2MKICBVTldJTkQoLnNhdmUge3IwIC0gcGN9CQkpCiAJc3ViCXNwLCBz cCwgIyhTX0ZSQU1FX1NJWkUgKyBcc3RhY2tfaG9sZSAtIDQpCiAjaWZkZWYg Q09ORklHX1RIVU1CMl9LRVJORUwKQEAgLTM0Nyw2ICszNDksNyBAQCBFTkRQ Uk9DKF9fcGFidF9zdmMpCiAJLm1hY3JvCXVzcl9lbnRyeQogIFVOV0lORCgu Zm5zdGFydAkpCiAgVU5XSU5EKC5jYW50dW53aW5kCSkJQCBkb24ndCB1bndp bmQgdGhlIHVzZXIgc3BhY2UKKwkuY2ZpX3N0YXJ0cHJvYwogCXN1YglzcCwg c3AsICNTX0ZSQU1FX1NJWkUKICBBUk0oCXN0bWliCXNwLCB7cjEgLSByMTJ9 CSkKICBUSFVNQigJc3RtaWEJc3AsIHtyMCAtIHIxMn0JKQpAQCAtNDI3LDYg KzQzMCw3IEBAIF9fZGFidF91c3I6CiAJbW92CXIyLCBzcAogCWFkcglsciwg QlNZTShyZXRfZnJvbV9leGNlcHRpb24pCiAJYglkb19EYXRhQWJvcnQKKwku Y2ZpX2VuZHByb2MKICBVTldJTkQoLmZuZW5kCQkpCiBFTkRQUk9DKF9fZGFi dF91c3IpCiAKQEAgLTQ1NCw2ICs0NTgsNyBAQCBfX2lycV91c3I6CiAKIAlt b3YJd2h5LCAjMAogCWIJcmV0X3RvX3VzZXIKKwkuY2ZpX2VuZHByb2MKICBV TldJTkQoLmZuZW5kCQkpCiBFTkRQUk9DKF9faXJxX3VzcikKIApAQCAtNDk2 LDYgKzUwMSw3IEBAIF9fdW5kX3VzcjoKICNlbHNlCiAJYglfX3VuZF91c3Jf dW5rbm93bgogI2VuZGlmCisJLmNmaV9lbmRwcm9jCiAgVU5XSU5EKC5mbmVu ZAkJKQogRU5EUFJPQyhfX3VuZF91c3IpCiAKQEAgLTY5MSw2ICs2OTcsNyBA QCBfX3BhYnRfdXNyOgogCWVuYWJsZV9pcnEJCQkJQCBFbmFibGUgaW50ZXJy dXB0cwogCW1vdglyMiwgc3AJCQkJQCByZWdzCiAJYmwJZG9fUHJlZmV0Y2hB Ym9ydAkJQCBjYWxsIGFib3J0IGhhbmRsZXIKKwkuY2ZpX2VuZHByb2MKICBV TldJTkQoLmZuZW5kCQkpCiAJLyogZmFsbCB0aHJvdWdoICovCiAvKgpAQCAt Njk5LDkgKzcwNiwxMSBAQCBfX3BhYnRfdXNyOgogRU5UUlkocmV0X2Zyb21f ZXhjZXB0aW9uKQogIFVOV0lORCguZm5zdGFydAkpCiAgVU5XSU5EKC5jYW50 dW53aW5kCSkKKwkuY2ZpX3N0YXJ0cHJvYwogCWdldF90aHJlYWRfaW5mbyB0 c2sKIAltb3YJd2h5LCAjMAogCWIJcmV0X3RvX3VzZXIKKwkuY2ZpX2VuZHBy b2MKICBVTldJTkQoLmZuZW5kCQkpCiBFTkRQUk9DKF9fcGFidF91c3IpCiBF TkRQUk9DKHJldF9mcm9tX2V4Y2VwdGlvbikKZGlmZiAtLWdpdCBhL2FyY2gv YXJtL2tlcm5lbC9lbnRyeS1oZWFkZXIuUyBiL2FyY2gvYXJtL2tlcm5lbC9l bnRyeS1oZWFkZXIuUwppbmRleCAwNTExNjZjLi41ZWQxM2FlIDEwMDY0NAot LS0gYS9hcmNoL2FybS9rZXJuZWwvZW50cnktaGVhZGVyLlMKKysrIGIvYXJj aC9hcm0va2VybmVsL2VudHJ5LWhlYWRlci5TCkBAIC04Niw2ICs4Niw3IEBA CiAjZWxzZQogCWxkbWlhCXNwLCB7cjAgLSBwY31eCQkJQCBsb2FkIHIwIC0g cGMsIGNwc3IKICNlbmRpZgorCS5jZmlfZW5kcHJvYwogCS5lbmRtCiAKIAku bWFjcm8JcmVzdG9yZV91c2VyX3JlZ3MsIGZhc3QgPSAwLCBvZmZzZXQgPSAw Cg== --20cf307ac3d370614604a6c47e1e--