Re: Debugging GDB with GDB

[Michael Snyder <Michael.Snyder@palmsource.com>]

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.


> ----------------------------------------------------------
> <start_session>
> 
> 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)
> 
> <end_session>
> ----------------------------------------------------------
> 
> 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.