Re: About bfd in gdb

[Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>]

Hi there,

<snip>

> <>
> 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 )