From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30762 invoked by alias); 31 Aug 2006 17:43:35 -0000 Received: (qmail 30754 invoked by uid 22791); 31 Aug 2006 17:43:34 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Aug 2006 17:43:29 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 042AF26B89; Thu, 31 Aug 2006 10:43:28 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00381-01-8; Thu, 31 Aug 2006 10:43:26 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 777D826B66; Thu, 31 Aug 2006 10:43:26 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Aug 2006 17:43:26 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 31 Aug 2006 10:43:25 -0700 Subject: Re: Debugging GDB with GDB From: Michael Snyder To: Rajesh Warange Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 31 Aug 2006 17:43:00 -0000 Message-Id: <1157046205.4466.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00283.txt.bz2 On Thu, 2006-08-31 at 21:47 +0530, Rajesh Warange wrote: > Hi all, > Thanks Jim and Michael for giving me a start to GDB. > > I am trying to debug GDB with GDB. I have built a target for ARM (gdb-arm). > So I am debugging gdb-arm with gdb. Congratulations. You are entering a domain where few dare to go. ;-) > Below is a session output I had. > I have explained my problem below. Two suggestions will make your work much easier. 1) The "set prompt" command changes the gdb prompt. I use it so that I always know which gdb's prompt I am looking at. My personal habit is to set the "outer" gdb to "(GDB)", but this is of course a matter of preference. 2) Build your arm gdb with optimization turned off. Optimization is what is causing the "jumping around" behavior that you're experiencing. This should be as simple as: a) make clean b) make CFLAGS=-g (since by default, CFLAGS is "-g -O2", you are overriding the -O2). You aren't going to be bothered by poor performance debugging an un-optimized gdb, but you *will* be bothered by many little issues with debugging optimized code. > ---------------------------------------------------------- > > > GNU gdb Red Hat Linux (6.3.0.0-1.63rh) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Setting up the environment for debugging gdb. > No symbol table is loaded. Use the "file" command. > No symbol table is loaded. Use the "file" command. > .gdbinit:8: Error in sourced command file: > No breakpoint number 0. > (gdb) file gdb > Reading symbols from /home/warangr/gdb-6.5-build/gdb/gdb...done. > Using host libthread_db library "/lib64/tls/libthread_db.so.1". > (gdb) break _initialize_arm_tdep > Breakpoint 1 at 0x414b80: file ../../gdb-6.5/gdb/arm-tdep.c, line 2871. > (gdb) run > Starting program: /home/warangr/gdb-6.5-build/gdb/gdb > > Breakpoint 1, _initialize_arm_tdep () at ../../gdb-6.5/gdb/arm-tdep.c:2871 > 2871 { > (gdb) s > During symbol reading, Incomplete CFI data; unspecified register rax > at 0x0000000000414b82. > 2883 gdbarch_register (bfd_arch_arm, arm_gdbarch_init, arm_dump_tdep); > (gdb) s > 2871 { > (gdb) s > 2881 size_t rest = sizeof (regdesc); > (gdb) s > 2871 { > (gdb) s > 2909 for (i = 0; i < num_disassembly_options; i++) > (gdb) > > > ---------------------------------------------------------- > > I started with setting a breakpoint at the function > _initialize_arm_tdep (defined in arm-tdep.c - line 2871). > When doing a single-step it jumped to line 2883 to a function > gdbarch_register (bfd_arch_arm, arm_gdbarch_init, arm_dump_tdep); > Now single stepping into this function would mean executing the first > line of the function gdbarch_register(bfd_....). > But it again jumps to line 2871 ... which is the start of the function > _initialize_arm_tdep. > Again after single-stepping, the debugger jumps to line 2909 executing > the "for loop". > There were some functions in between which it skipped entirely. > > I 'm pretty badly foxed by this behaviour. > Could anyone please explain me this > > Thanks.