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

[Ian Lance Taylor <ian@airs.com>]

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?

Ian