From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19078 invoked by alias); 2 Apr 2003 20:39:57 -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 18964 invoked from network); 2 Apr 2003 20:39:55 -0000 Received: from unknown (63.201.54.26) by sources.redhat.com with QMTP; 2 Apr 2003 20:39:55 -0000 Received: (qmail 23041 invoked by uid 10); 2 Apr 2003 18:53:13 -0000 Received: (qmail 18805 invoked by uid 500); 2 Apr 2003 18:53:08 -0000 Mail-Followup-To: gdb@sources.redhat.com, binutils@sources.redhat.com, nickc@redhat.com, drow@mvista.com To: Daniel Jacobowitz Cc: gdb@sources.redhat.com, binutils@sources.redhat.com, nickc@redhat.com Subject: Re: gdb.mi/mi-cli.exp failures References: <3E88AE3F.4030005@redhat.com> <3E89AB79.1060700@redhat.com> <3E89C7DB.3080906@redhat.com> <20030401182249.GB24160@nevyn.them.org> <20030402172825.GA32596@nevyn.them.org> <20030402180505.GA29974@nevyn.them.org> From: Ian Lance Taylor Date: Wed, 02 Apr 2003 20:39:00 -0000 In-Reply-To: <20030402180505.GA29974@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00033.txt.bz2 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. In principle, bfd_get_relocated_section_contents() should not expect to see the exact same sort of hash table that is generated by add_symbols(). It should work with any type of linker hash table. If it doesn't work, then linking to a different object file format will not work. The same applies to the HOWTO functions, of course. Of course, in practice linking to a different object file format may not be supported. But in general the HOWTO functions can't expect to see a linker hash table, since they are also called by the assembler. And there is no reason to write get_relocated_section_contents() to see a particular type of hash table, because it will never be called if you use add_symbols() and final_link(). So while I'm perfectly willing to believe that there is a problem, I don't know what it is. It seems to me that the simple.c code ought to be able to call _bfd_generic_link_add_symbols(), and we could make some guarantees about that specific function. If that doesn't work, then why doesn't it? Ian