From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1925 invoked by alias); 27 Jun 2011 14:59:20 -0000 Received: (qmail 1915 invoked by uid 22791); 27 Jun 2011 14:59:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_QE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Jun 2011 14:59:05 +0000 Received: (qmail 30893 invoked from network); 27 Jun 2011 14:59:04 -0000 Received: from unknown (HELO ?192.168.0.102?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Jun 2011 14:59:04 -0000 Message-ID: <4E089AB3.1090801@codesourcery.com> Date: Mon, 27 Jun 2011 14:59:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dmitry Eremin-Solenikov CC: gdb@sourceware.org, Russell King - ARM Linux , linux-arm-kernel@lists.infradead.org, Eric Miao Subject: Re: Problem with GDB when debugging IRQ handlers References: <20110627125306.GA30646@doriath.ww600.siemens.net> <20110627132735.GE16103@n2100.arm.linux.org.uk> <4E088DE1.2060809@gmail.com> In-Reply-To: <4E088DE1.2060809@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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/msg00149.txt.bz2 On 06/27/2011 10:04 PM, Dmitry Eremin-Solenikov wrote: > Hello, > > On 27.06.2011 17:27, Russell King - ARM Linux wrote: >> On Mon, Jun 27, 2011 at 04:53:06PM +0400, Dmitry Eremin-Solenikov wrote: >>> I've got into a problem when trying to debug irq handlers on PXA (in >>> qemu). backtrace is really strange from my POV (a target is just a qemu >>> running a bit modified 3.0-rc2 kernel): >> ... >>> Breakpoint 1, handle_level_irq (irq=42, desc=0xc3e06000) at >>> kernel/irq/chip.c:329 >>> 329 mask_ack_irq(desc); >>> (gdb) bt >>> #0 handle_level_irq (irq=42, desc=0xc3e06000) at kernel/irq/chip.c:329 >>> #1 0xc0085f64 in generic_handle_irq_desc (irq=42) at >>> include/linux/irqdesc.h:111 >>> #2 generic_handle_irq (irq=42) at kernel/irq/irqdesc.c:304 >>> #3 0xc0033060 in asm_do_IRQ (irq=42, regs=) at >>> arch/arm/kernel/irq.c:90 >>> #4 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #5 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #6 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #7 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #8 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #9 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #10 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #11 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> #12 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202 >>> >>> ... and so on it continues ad infinitum. Is it the expected behaviour? >>> Because I'm pretty much sure that this isn't a desired behaviour. >> Usually, if debugging information is not there, GDB will try to unwind stacks by analyzing function's prologue. It looks arm prologue analyzer goes into an endless loop, because of (I guess) the irregular register usage in low-level kernel asm code. arm/gdb's prologue analyzer can handle common code, but I am afraid it is unable to handle kernel-specific code, unless we make gdb kernel-aware. At least, we may teach gdb to stop at __irq_svc. Please file a bug report against gdb, and post the disassembly of __irq_svc in bug report. >> 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). -- Yao (齐尧)