From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14355 invoked by alias); 28 Jun 2011 12:09:57 -0000 Received: (qmail 14337 invoked by uid 22791); 28 Jun 2011 12:09:57 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 12:09:42 +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 1QbX6f-0002si-UK; Tue, 28 Jun 2011 13:09:30 +0100 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.72) (envelope-from ) id 1QbX6e-0006f0-K6; Tue, 28 Jun 2011 13:09:28 +0100 Date: Tue, 28 Jun 2011 12:09:00 -0000 From: Russell King - ARM Linux To: Hui Zhu Cc: Yao Qi , 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: <20110628120928.GD21898@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00154.txt.bz2 On Tue, Jun 28, 2011 at 08:06:27PM +0800, Hui Zhu wrote: > If this kernel didn't open FRAME_POINTER, what will happen? I can't answer that question directly, as I don't use a toolchain new enough to generate proper unwind information. However, I haven't seen any problems being reported on the list with bad/broken backtraces from the kernel, so my _assumption_ is that the kernel is fine with its own debug info.