From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8547 invoked by alias); 1 Apr 2003 18:23:02 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8482 invoked from network); 1 Apr 2003 18:23:01 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 1 Apr 2003 18:23:01 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 190QPO-0006UH-00; Tue, 01 Apr 2003 12:22:54 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 190QPJ-0006ko-00; Tue, 01 Apr 2003 13:22:49 -0500 Date: Tue, 01 Apr 2003 18:23:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Nick Clifton , carlton@math.stanford.edu, gdb , binutils@sources.redhat.com Subject: Re: gdb.mi/mi-cli.exp failures Message-ID: <20030401182249.GB24160@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Nick Clifton , carlton@math.stanford.edu, gdb , binutils@sources.redhat.com References: <3E88A369.6090403@redhat.com> <3E88AE3F.4030005@redhat.com> <3E89AB79.1060700@redhat.com> <3E89C7DB.3080906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E89C7DB.3080906@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00011.txt.bz2 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