From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21024 invoked by alias); 8 Oct 2004 05:53:23 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 21017 invoked from network); 8 Oct 2004 05:53:22 -0000 Received: from unknown (HELO gizmo02ps.bigpond.com) (144.140.71.12) by sourceware.org with SMTP; 8 Oct 2004 05:53:22 -0000 Received: (qmail 7678 invoked from network); 8 Oct 2004 05:53:20 -0000 Received: from unknown (HELO psmam12.bigpond.com) (144.135.25.103) by gizmo02ps.bigpond.com with SMTP; 8 Oct 2004 05:53:20 -0000 Received: from cpe-144-136-221-26.sa.bigpond.net.au ([144.136.221.26]) by psmam12.bigpond.com(MAM REL_3_4_2a 234/94310137) with SMTP id 94310137; Fri, 08 Oct 2004 15:53:20 +1000 Received: by bubble.modra.org (Postfix, from userid 500) id 0AEA044858; Fri, 8 Oct 2004 15:23:19 +0930 Date: Fri, 08 Oct 2004 05:53:00 -0000 From: Alan Modra To: Jan Beulich Cc: binutils@sources.redhat.com Subject: Re: gas rearranging elf file symbols Message-ID: <20041008055319.GM12632@bubble.modra.org> Mail-Followup-To: Jan Beulich , binutils@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2004-10/txt/msg00106.txt.bz2 On Wed, Oct 06, 2004 at 10:31:30AM +0200, Jan Beulich wrote: > After enabling elf_find_function to actually report a filename if any > can be found, it became immediately obvious that gas prevents this from > being fully functional. This is because gas (a) emits all the file > symbols (resulting from # "", .file, or .appfile) in a > block and (b) inverts the sequence in which they were encountered. With > this, associating a local symbol with its (pseudo-)source file name is > impossible. > > Is anyone able to explain why this works the way it does currently? I'm not sure why the file symbols are reversed, but it looks to be intentional. See config/obj-elf.c:elf_file_symbol. This has the effect of putting the sym for the main source file last, which then is the one that always matches in elf_find_function. As you say, that might not be the correct file. You can't do better for globals of course, since global symbols are placed after local symbols, losing any association you might infer from the symbol ordering. While looking at this, I noticed that all file syms starting with ".." were being dropped. * syms.c (bfd_is_local_label): Return false for file symbols. Index: bfd/syms.c =================================================================== RCS file: /cvs/src/src/bfd/syms.c,v retrieving revision 1.37 diff -u -p -r1.37 syms.c --- bfd/syms.c 5 Oct 2004 11:12:56 -0000 1.37 +++ bfd/syms.c 8 Oct 2004 05:52:23 -0000 @@ -355,7 +355,7 @@ bfd_is_local_label (bfd *abfd, asymbol * /* The BSF_SECTION_SYM check is needed for IA-64, where every label that starts with '.' is local. This would accidentally catch section names if we didn't reject them here. */ - if ((sym->flags & (BSF_GLOBAL | BSF_WEAK | BSF_SECTION_SYM)) != 0) + if ((sym->flags & (BSF_GLOBAL | BSF_WEAK | BSF_FILE | BSF_SECTION_SYM)) != 0) return FALSE; if (sym->name == NULL) return FALSE; -- Alan Modra IBM OzLabs - Linux Technology Centre