This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb.mi/mi-cli.exp failures
On Wed, Apr 02, 2003 at 10:53:08AM -0800, Ian Lance Taylor wrote:
> 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?
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