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

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Apr 01, 2003 at 12:09:47PM -0500, Andrew Cagney wrote:
> >Hi Andrew,
> >
> >
> >>Unfortunatly BFD changed an interface right in the middle of this -
> >>it's put GDB/BFD into a death spiral :-(
> >
> >
> >Die evil GDB die ... :-)
> >
> >
> >>FAIL: gdb.base/relocate.exp: get address of static_bar (timeout)
> >>FAIL: gdb.base/relocate.exp: static variables have different addresses
> >>FAIL: gdb.base/relocate.exp: get address of global_foo (timeout)
> >>FAIL: gdb.base/relocate.exp: get address of global_bar (timeout)
> >>FAIL: gdb.base/relocate.exp: global variables have different addresses
> >>FAIL: gdb.base/relocate.exp: get address of function_foo (timeout)
> >>FAIL: gdb.base/relocate.exp: get address of function_bar (timeout)
> >>FAIL: gdb.base/relocate.exp: functions have different addresses
> >
> >
> >Hmm, I currently do not see these failures.  In fact I do not see any
> >failures running the relocate.exp script with the latest GDB and
> >BINUTILS sources.  Have you fixed something already ?
> 
> I see these failures on both i386 RH 7.2 native and PPC X d10v-elf using 
> a gdb+dejagnu source tree.  It occures in both current and with a 
> 2003-03-31-gmt tree containing just that simple.c change.
> 
> I should note that these are both elf + stab targets.

Aha!  That was the missing piece.  I see two problems and I'd like
feedback from binutils maintainers on them.

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?

Can I not rely on section_count remaining stable for an input BFD?


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 ().

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer