From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1229 invoked by alias); 4 Jul 2004 14:00:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1183 invoked from network); 4 Jul 2004 14:00:27 -0000 Received: from unknown (HELO calvin.codito.co.in) (203.199.140.162) by sourceware.org with SMTP; 4 Jul 2004 14:00:27 -0000 Received: from [192.168.100.52] (ramana.codito.co.in [192.168.100.52]) by calvin.codito.co.in (8.12.10/8.12.10) with ESMTP id i64DvA0l030876; Sun, 4 Jul 2004 19:27:11 +0530 Message-ID: <40E80D65.1040501@codito.com> Date: Sun, 04 Jul 2004 14:00:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla Thunderbird 0.6 (X11/20040605) MIME-Version: 1.0 To: libra CC: gdb@sources.redhat.com Subject: Re: About bfd in gdb References: <1088948153.40e807b9434db@webmail.cs.nthu.edu.tw> In-Reply-To: <1088948153.40e807b9434db@webmail.cs.nthu.edu.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00023.txt.bz2 Hi there, > <> > 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) { 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 )