This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About bfd in gdb


At first, thanks for your reply.

After survey the gdb source code,i can roughly take the gdb source code into 
two part, one is gdb and the other is sim. (Maybe now, it must add the third 
part that is binutils(bfd and opcodes))

My question is :
Because the gdb source code is complex, i do not know how these two part(gdb 
and sim) communicate with each other.In other word, which file is the 
interface that can connect these two part.Once i add a new simulator(sim ,ISA)
into the gdb source code, the gdb can connct to my new sim,and run my program 
on the new sim and debug it. Any documentation can reference


My idea is that the gdb is just an interface that connect to the simulator(sim)
, after doing that i can run my own program and debug it (ex:use arm-elf-gdb 
or just use the simulator arm-elf-run).

                                                            thanks a lot!!


----- Original Message ----- 
From: "Ramana Radhakrishnan" <ramana.radhakrishnan@codito.com>
To: "libra" <mr924352@cs.nthu.edu.tw>
Cc: <gdb@sources.redhat.com>
Sent: Sunday, July 04, 2004 10:00 PM
Subject: Re: About bfd in gdb


> > Why we must build the bfd and opcodes parts that the same as in 
> > binutils (like
> > archures.c reloc.c arm-dis.c and arm-opc.h and so on)
> >
> > My idea is that :
> > We just need to build bfd inoder to recognize the input file format,then
> > i can use the gdb to connect to simulator(sim),after that, I can run 
> > my own
> > program.
> > So, the aboved mentioned file (ex: arm-dis.c and arm-opc.h), why is 
> > those file
> > must be built again. It seem does not be used in gdb.
> 
> This would be needed for doing all the reading of the object file. The 
> most common cases that come to mind off the cuff are:
> 
> 1. The implementation of the disassembling would be based on the 
> disassembling in the opcodes library.
>    Just taking your example. For the ARM if you trace the disassembling 
> function in arm-tdep.c you would observe that it returns the function
>    print_insn_little_arm or print_insn_big_arm depending on the 
> endian-ness . These functions happen to be defined in opcodes/arm-dis.c and
>    there would be a dependency between the two of them.
>     "code pasted below for your reference "
>   
> CVS today ..
>     File: gdb/ arm-tdep.c
>     Function :
> 
>   gdb_print_insn_arm (bfd_vma memaddr, disassemble_info *info)
>   {
> 
>     <blah>
>    
> 
>  if (TARGET_BYTE_ORDER == BFD_ENDIAN_BIG)
>     return print_insn_big_arm (memaddr, info);
>   else
>     return print_insn_little_arm (memaddr, info);
>   }
> 
>   and you can find both these functions defined in opcodes/arm-dis.c 
> 
> 
> 2.  Construction of minimal symbol tables for the debugger.
> 3.  Reading any information from the executable file would use the bfd 
> library.Since all information about the executable for the debugger 
> happens to be in the
> executable file in the case of the ELF file format gdb would 
> automatically have a dependency with the opcodes and bfd library.
> 
> cheers
> Ramana
> 
> ---
> Ramana Radhakrishnan
> GNU Tools
> codito ergo sum (www.codito.com )
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]