From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18985 invoked by alias); 2 Apr 2003 17:21:23 -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 18917 invoked from network); 2 Apr 2003 17:21:20 -0000 Received: from unknown (63.201.54.26) by sources.redhat.com with QMTP; 2 Apr 2003 17:21:20 -0000 Received: (qmail 21096 invoked by uid 10); 2 Apr 2003 17:21:18 -0000 Received: (qmail 18385 invoked by uid 500); 2 Apr 2003 17:21:13 -0000 Mail-Followup-To: drow@mvista.com, gdb@sources.redhat.com, binutils@sources.redhat.com, nickc@redhat.com To: Nick Clifton Cc: drow@mvista.com, 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: Ian Lance Taylor Date: Wed, 02 Apr 2003 17:21:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00028.txt.bz2 Nick Clifton writes: > > 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 ?) I created a .stabstr section in the input file because I needed to have a section in an input file which the linker script could put into the output file correctly. This is not the only place where this trick is used. Using an existing .stabstr section would have to be handled carefully. The code would have to extract the information, and arrange to replace it in the output file. This might not be too hard. Creating the .stabstr section in the output BFD doesn't work, because it won't let the linker script function properly. > > 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. Well, I'm afraid that you will have to deal with a number of other cases if you want to avoid adding sections to input files. Take a look at elf_link_create_dynamic_sections(). Ian