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

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Apr 02, 2003 at 06:06:05PM +0100, Nick Clifton wrote:
> Hi Daniel,
> 
> > 1.  stabs.c can create a new section while reading stabs from an input
> > BFD.  This means that I can't save and restore a per-section datum
> > (output_offset and output_section) around a call to
> > bfd_link_add_symbols.
> > 
> > #0  bfd_section_init (abfd=0x8277980, newsect=0x827b9b4) at /opt/src/gdb/src/bfd/section.c:734
> > #1  0x0818039d in _bfd_link_section_stabs (abfd=0x8277980, psinfo=0x827855c, stabsec=0x827cae8,
> >     stabstrsec=0x827cb7c, psecinfo=0x827b9c0) at /opt/src/gdb/src/bfd/stabs.c:240
> > #2  0x081501d6 in elf_link_add_object_symbols (abfd=0x8277980, info=0xbfffe0b0)
> >     at /opt/src/gdb/src/bfd/elflink.h:2305
> > #3  0x08148f8b in bfd_simple_get_relocated_section_contents (abfd=0x8277980, sec=0x827cae8,
> >     outbuf=0x828f868 "", symbol_table=0x0) at /opt/src/gdb/src/bfd/simple.c:247
> > 
> > It's doing this:
> > 	sinfo->stabstr = bfd_make_section_anyway (abfd, ".stabstr");
> > which doesn't make much sense to me; there's _already_ a section named
> > .stabstr in the executable, why not use that one?
> 
> Hmm, agreed - this probably ought to be a call to
> bfd_get_section_by_name().  And if that fails then the code should try
> to find the output bfd and create the section there.  (Either that or
> else return a failure result.  Can you have a .stabs section without a
> .stabsstr section ?)

Not one that makes much sense.  The stabs data contains string table
indices... Even N_SO will have a string reference.

> > Can I not rely on section_count remaining stable for an input BFD?
> 
> I think that you ought to be able to rely on this.

OK, then fixing stabs.c will take care of one of the problems.

> > 2.  We call bfd_simple_get_relocated_section_contents twice on the same
> > section.  The second time, it crashes.  It appears that pointers to the
> > symbol table are stored in the canonicalized relocations, in
> > elf_slurp_reloc_table_from_section.  This means that the symbol table
> > can no longer be freed.  Should it be allocated via bfd_alloc instead
> > of bfd_malloc?
> 
> > Note that this is a significant change, since we're talking about the
> > pointer table, i.e. the area of size bfd_get_symtab_upper_bound ().
> 
> Plus we would now have to ensure that the caller has allocated the
> memory in the same bfd, it is passing in the 'symbol_table' pointer.
> 
> However, since the relocs are persistent, I think that the symbols
> that they use need to be persistent too.  Hence we need to use
> bfd_alloc.

However, bfd_get_symtab_upper_bound is an exported interface. 
bfd_alloc is not.  We'd have to say that a caller could not free the
result of bfd_canonicalize_symtab until after closing the BFD.  Gross!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer