This is the mail archive of the
mailing list for the GDB project.
Re: gdb.mi/mi-cli.exp failures
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, carlton at math dot stanford dot edu,gdb <gdb at sources dot redhat dot com>, binutils at sources dot redhat dot com
- Date: Tue, 1 Apr 2003 13:22:49 -0500
- Subject: Re: gdb.mi/mi-cli.exp failures
- References: <ro14r5j1g87.fsf@jackfruit.Stanford.EDU> <3E88A369.firstname.lastname@example.org> <3E88AE3F.email@example.com> <firstname.lastname@example.org> <3E89AB79.email@example.com> <firstname.lastname@example.org> <3E89C7DB.email@example.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
#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)
#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
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 ().
MontaVista Software Debian GNU/Linux Developer