From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22130 invoked by alias); 10 Feb 2020 05:21:14 -0000 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 Received: (qmail 22112 invoked by uid 89); 10 Feb 2020 05:21:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=explained, group's X-HELO: mail-pl1-f177.google.com Received: from mail-pl1-f177.google.com (HELO mail-pl1-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Feb 2020 05:21:10 +0000 Received: by mail-pl1-f177.google.com with SMTP id a6so2350174plm.3 for ; Sun, 09 Feb 2020 21:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WjIL0+OM6aQTpl/MW8B1czkAVYCzMnKuRkIElZkifFQ=; b=vIOsAfaHme45v68Nuqyr+vgkuHl+ssou0Y9byUn/YvPkc1ouk+2sUdWi+PuWeTJNAw GGvEgTTEagPi7Rw5kav+W3X1wHWiPwSDEjcU8Qd+8ZhBzSeiFAkhLfBogNNttotB40Kw 01RLHMkvtSZkhiiKxAFwePDReUihLpOxsxFColW3LJgrZA/cYxLZA7Grw+JNwS5TgQc+ kIrZwOzcSO00L0fT71MYDON2J7Z82ViY97jODa2LEkWXKMSlQkY2yS9AtfaAEFyjd5Yb KKa8CsOKvjwCrethTk63OjjHKcADx5QvnmSxfKa+snh7Nv/o6ArPcI3GCd5QudAs09Ks t7Yg== Return-Path: Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:d5a4:7e63:5182:cf65]) by smtp.gmail.com with ESMTPSA id i190sm1963563pgd.75.2020.02.09.21.21.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Feb 2020 21:21:08 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 1730B85804; Mon, 10 Feb 2020 15:51:05 +1030 (ACDT) Date: Mon, 10 Feb 2020 05:21:00 -0000 From: Alan Modra To: bd1976 llvm Cc: Fangrui Song , binutils@sourceware.org Subject: Re: .section directives with the same name but different fields Message-ID: <20200210052104.GQ5669@bubble.grove.modra.org> References: <20200206073837.j4biw4rsbdy2siip@gmail.com> <20200206083347.GC5669@bubble.grove.modra.org> <20200206091914.5docw46nvgx7om6o@google.com> <20200206140912.GE5669@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00130.txt.bz2 On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: > Hi Alan, thanks for the input here. I wonder if it wouldn't be more > consistent to error in all cases - even in the case of different group > signatures. The only exception would need to be for the special section > names (.text, .debug_str, etc...) that the assembler has special knowledge > of (as you explained). Yes, let's see how that goes. https://sourceware.org/ml/binutils/2020-02/msg00129.html > I wonder why creating multiple sections with the > same name for section directives with different group signatures was > implemented - why not just require the use of a distinct section name for > these? I think plain ".text" for a group's text section is fine. Distict names would just be yet another thing to track for a group. > Or, now that GNU has the ",unique,N" assembly extension ( > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be > used if the section name is fixed - it would then be explicit in the source > code that another section with the same name will be created. Perhaps, but we aren't designing a new toolchain. Backwards compatibility can't be discarded without compelling reasons. -- Alan Modra Australia Development Lab, IBM