From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22123 invoked by alias); 12 Jul 2002 16:50:43 -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 22115 invoked from network); 12 Jul 2002 16:50:43 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 12 Jul 2002 16:50:43 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 86DCE5EA11; Fri, 12 Jul 2002 11:50:41 -0500 (EST) To: Dan Towner Cc: gdb@sources.redhat.com Subject: Re: New object file parser? References: <3D2EFDE0.159BCF83@picochip.com> From: Jim Blandy Date: Fri, 12 Jul 2002 09:50:00 -0000 In-Reply-To: <3D2EFDE0.159BCF83@picochip.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00133.txt.bz2 Dan Towner writes: > I am porting gdb to a new processor architecture (embedded > multi-processor DSP). Currently, although we use gcc as our compiler, we > have a proprietary assembler and linker, which generate non-standard > object and executable files. Now, faced with the task of getting the > symbol table information from the object file through to gdb, is it > easier to: > > 1) Write a new parser for BFD. > > or > > 2) Write a converter which generates a standard object file format from > our proprietary format. Well, you've made your bed... :) > Whichever route I take, which object file would be the easier to deal > with? From what I have seen, I think that a.out would be the best, but > is there anything simpler? Well, there's S-records. I don't know if they can carry symbol information, though. I think not. If you need a symbol table, I'd say a.out is probably the simplest one there is. You can probably find documentation for a.out in the SunOS 4 man pages, or perhaps somewhere on the Web. The next question is, what debugging format do you use? Converting debugging info from the proprietary format to STABS or Dwarf is going to be the hard part, I'd bet.