gdb.mi/mi-cli.exp failures
Daniel Jacobowitz
drow@mvista.com
Wed Apr 2 17:13:00 GMT 2003
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
More information about the Binutils
mailing list