Re: gdb.mi/mi-cli.exp failures

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Apr 02, 2003 at 10:53:08AM -0800, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@mvista.com> 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?

It appears to work, and fixes one of the two problems.  I'll post a
patch in a little while.  This doesn't solve the question of freeing
the symbol table; I suppose that using bfd_alloc for it may be the way
to go.

Note that this still isn't ideal, because the symbol table is not
clearly cached in the BFD anywhere; so we'll get a new one each time we
relocate a section.  What we really need is to cache the canonicalized
symbol table, I suppose.

Really, BFD isn't set up to work the way I want it to for this
functionality.  I don't know what to do to make it better.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer