This is the mail archive of the
mailing list for the GDB project.
Re: gdb.mi/mi-cli.exp failures
Daniel Jacobowitz <drow at mvista dot 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?