From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19986 invoked by alias); 21 Oct 2010 00:18:39 -0000 Received: (qmail 19975 invoked by uid 22791); 21 Oct 2010 00:18:36 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-pw0-f41.google.com (HELO mail-pw0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Oct 2010 00:18:32 +0000 Received: by pwj3 with SMTP id 3so509655pwj.0 for ; Wed, 20 Oct 2010 17:18:30 -0700 (PDT) Received: by 10.142.200.2 with SMTP id x2mr110325wff.326.1287620310685; Wed, 20 Oct 2010 17:18:30 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id y42sm1264255wfd.22.2010.10.20.17.18.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 17:18:28 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 58C51170C206; Thu, 21 Oct 2010 10:48:23 +1030 (CST) Date: Thu, 21 Oct 2010 00:18:00 -0000 From: Alan Modra To: mark@codesourcery.com Cc: binutils@sourceware.org Subject: Re: RFC: COMDAT group names become anonymouse local symbols Message-ID: <20101021001823.GQ26553@bubble.grove.modra.org> Mail-Followup-To: mark@codesourcery.com, binutils@sourceware.org References: <20101019200838.8A9725664F9@henry1.codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101019200838.8A9725664F9@henry1.codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-10/txt/msg00332.txt.bz2 On Tue, Oct 19, 2010 at 01:08:38PM -0700, Mark Mitchell wrote: > > When assembling this trivial file: > > .section A,"axG",%progbits,B,comdat > # Note that there is no definition of the symbol B. > > GAS generates a COMDAT group whose "signature" (in the sense of the > ELF spec) is an anonymous local symbol: > > Section Headers: > [Nr] Name Type Address Off Size ES Flg Lk Inf Al > [ 1] B GROUP 0000000000000000 000040 000008 04 7 5 4 > > Symbol table '.symtab' contains 6 entries: > Num: Value Size Type Bind Vis Ndx Name > 5: 0000000000000000 0 SECTION LOCAL DEFAULT 1 > > This seems bad. The documentation for the .section directive says > that B is the group name, and since the linker's collapsing of COMDAT > groups is done based on the *signature*, not the name referred to by > the section header itself, this seems wrong. I don't see anything bad about this (except possibly if you are using a linker other than GNU ld or gold). That isn't an "anonymous" local symbol. That is the section symbol for the group section named "B". GNU ld saves .strtab space by leaving st_name zero on section symbols; The name of such a symbol is given by the section sh_name. So the group signature is indeed "B". In cases like this, where a non-section symbol having the same name a the group signature does not already exist, gas could create a normal local symbol just for the group name. You'd then get the group name in .strtab *and* you'd have ".group" in .shstrtab. With the current gas fallback, you just have the group name in .shstrtab. I'll grant that is not much of a saving, but when I first wrote the gas group support, gas always named the group section with the name of the group signature. It seemed reasonable to leave that as a fallback when a non-section symbol with the group name does not exist. > On the other hand, perhaps GCC shouldn't generate code like this. (It > does, at present, for certain C++ inputs.) The assembler certainly > shouldn't create a global symbol named "B". If the assembler were to > create a local symbol with the name "B", would the linker still > combine this COMDAT group with another group in another object file > also named "B", even if both had different local symbols as their > signatures? Yes. -- Alan Modra Australia Development Lab, IBM