From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12457 invoked by alias); 2 Apr 2003 18:05:08 -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 12437 invoked from network); 2 Apr 2003 18:05:07 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 2 Apr 2003 18:05:07 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 190mbl-0008Tn-00; Wed, 02 Apr 2003 12:05:09 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 190mbh-00087m-00; Wed, 02 Apr 2003 13:05:05 -0500 Date: Wed, 02 Apr 2003 18:05:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com, binutils@sources.redhat.com, nickc@redhat.com Subject: Re: gdb.mi/mi-cli.exp failures Message-ID: <20030402180505.GA29974@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com, binutils@sources.redhat.com, nickc@redhat.com References: <3E88AE3F.4030005@redhat.com> <3E89AB79.1060700@redhat.com> <3E89C7DB.3080906@redhat.com> <20030401182249.GB24160@nevyn.them.org> <20030402172825.GA32596@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00031.txt.bz2 On Wed, Apr 02, 2003 at 09:44:07AM -0800, Ian Lance Taylor wrote: > Daniel Jacobowitz writes: > > > Well, do you have another suggestion for how to approach this? We're > > not actually linking; but I need to get the symbols from the input file > > into a symbol table with forged offsets in order to apply relocations > > against them. > > Well, I don't really know the context. If you're not linking, then it > seems to me that you'll be better off avoiding the linking calls. The > add_symbols() call is the first phase of a link, and is expected to be > followed by the second phase of a link; despite the name > add_symbols(), it doesn't just add symbols to a hash table. > > If you really just want to put the symbols into a hash table, can you > just get the symbol table generically and add them to a hash table > yourself? IIRC, then we may get a different kind of hash table than the platform's relocation application functions expect. It's been a little while though. The context is in bfd/simple.c if you want to look at it. The intention is to use this code for both gdb and objdump (they do use it now, to be more accurate) to relocate the contents of debug sections. This is necessary for the general cases of debugging shared objects and unlinked object modules. > > > Well, I'm afraid that you will have to deal with a number of other > > > cases if you want to avoid adding sections to input files. Take a > > > look at elf_link_create_dynamic_sections(). > > > > In any case I can remove the assumption; it's not hard. I assume that > > if I save pointers to the sections present before calling > > elf_link_add_object_symbols, that they'll still be valid when it > > returns? > > Probably. But I personally don't think the add_symbols() routine > needs to make any guarantees at all, except that if you hook up and > the sections and call final_link() you will get a linked output file. > Maybe we should change the name add_symbols() to initial_link(). > > Ian > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer