From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7908 invoked by alias); 2 Apr 2003 17:06:18 -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 7726 invoked from network); 2 Apr 2003 17:06:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Apr 2003 17:06:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h32H6Fe23261; Wed, 2 Apr 2003 12:06:15 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h32H6FJ07790; Wed, 2 Apr 2003 12:06:15 -0500 Received: from workshop.nickc.cambridge.redhat.com.redhat.com (vpn50-12.rdu.redhat.com [172.16.50.12]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h32H6B508650; Wed, 2 Apr 2003 12:06:13 -0500 To: drow@mvista.com Cc: gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: gdb.mi/mi-cli.exp failures References: <3E88A369.6090403@redhat.com> <3E88AE3F.4030005@redhat.com> <3E89AB79.1060700@redhat.com> <3E89C7DB.3080906@redhat.com> <20030401182249.GB24160@nevyn.them.org> From: Nick Clifton Date: Wed, 02 Apr 2003 17:06:00 -0000 In-Reply-To: <20030401182249.GB24160@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00024.txt.bz2 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 ?) > 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. > 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. Cheers Nick