From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31055 invoked by alias); 30 Mar 2011 08:23:55 -0000 Received: (qmail 31044 invoked by uid 22791); 30 Mar 2011 08:23:53 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Mar 2011 08:23:49 +0000 Received: (qmail 22546 invoked from network); 30 Mar 2011 08:23:48 -0000 Received: from unknown (HELO ?84.152.190.210?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Mar 2011 08:23:48 -0000 Message-ID: <4D92E807.9020804@codesourcery.com> Date: Wed, 30 Mar 2011 08:23:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: "Joseph S. Myers" CC: binutils@sources.redhat.com, Paul Brook Subject: Re: Patch: Add c6x-uclinux support References: <4D7A0A32.7070308@codesourcery.com> <4D9116AD.9040809@codesourcery.com> <4D9263BC.7080309@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2011-03/txt/msg00548.txt.bz2 On 03/30/2011 01:42 AM, Joseph S. Myers wrote: > On Wed, 30 Mar 2011, Bernd Schmidt wrote: > >>> I'm happy with the directive, and given your other comments with the >>> section index (though it appears there must have been an omission to put >>> this index into the latest ABI version, which postdates the discussion you >>> mention). But why is the additional section *name* needed? How does it >>> differ from .bss? >> >> Oh, ok. To be honest - all this code is just copied from other ports, so >> I think "precedent" would be the reason. I'd prefer not to diverge >> unnecessarily from existing practice. >> >> Looking at it now, it seems to me that common symbols require the >> behavior enabled by >> . {* The section contains common symbols (symbols may be defined >> . multiple times, the value of a symbol is the amount of >> . space it requires, and the largest symbol value is the one >> . used). Most targets have exactly one of these (which we >> . translate to bfd_com_section_ptr), but ECOFF has two. *} >> .#define SEC_IS_COMMON 0x1000 >> >> This is tested in a few places in elflink.c for example. >> >> Are you specifically worried about code in the assembler or the linker, >> or both? > > I'm generally concerned that I don't understand why there are three > sections rather than two here. Why isn't .bss being given this property > and used in place of .scommon? Because it contains symbols that aren't common? I'm not sure I understand the question, really. Bernd