From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97269 invoked by alias); 6 Feb 2020 14:09:22 -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 97233 invoked by uid 89); 6 Feb 2020 14:09:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=D*11, U*2020, 202011, one-pass X-HELO: mail-pj1-f41.google.com Received: from mail-pj1-f41.google.com (HELO mail-pj1-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2020 14:09:19 +0000 Received: by mail-pj1-f41.google.com with SMTP id ep11so30627pjb.2 for ; Thu, 06 Feb 2020 06:09:18 -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=IMpc8uFeuHg/LaeUMlYPq1YnLYicZ3W0s6H29e7+W5c=; b=TUmGEEzeh4CUvMsfEgpK+U0FEx83E6bFsRGdaSAgC8rT6sHDYU7Io3iuf2v2YmmeKy 1yYJMsp2BsTo+YpOqvJOYiPs0KB4iPmu6sGhTawl3tkN+/SmloM/JDWSXTbbxV/WlQx7 3yckBm7XOESzKd1Flu3kCoSiUPWxFlikBUFOZFwDO6UciAJxXSqXnnNtbqFoi7GfJGUO KwYx4ixGrgwP15eZYHj1Pjss8E1Qh+zl32H17WgCDB+XKbjhJqb2Pq8ajMlqydzVc5zj FCLZqpr68TMtuHh27Cb0/BfZ7LjqUg1g27C7QZg2ofDdvHZa2dkoPzaUM2aL/+KXe1lj aYkg== Return-Path: Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id z30sm3739725pfq.154.2020.02.06.06.09.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Feb 2020 06:09:16 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id C4270805F9; Fri, 7 Feb 2020 00:39:12 +1030 (ACDT) Date: Thu, 06 Feb 2020 14:09:00 -0000 From: Alan Modra To: Fangrui Song Cc: binutils@sourceware.org, bd1976llvm@gmail.com Subject: Re: .section directives with the same name but different fields Message-ID: <20200206140912.GE5669@bubble.grove.modra.org> References: <20200206073837.j4biw4rsbdy2siip@gmail.com> <20200206083347.GC5669@bubble.grove.modra.org> <20200206091914.5docw46nvgx7om6o@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200206091914.5docw46nvgx7om6o@google.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00099.txt.bz2 On Thu, Feb 06, 2020 at 01:19:14AM -0800, Fangrui Song wrote: > On 2020-02-06, Alan Modra wrote: > > On Wed, Feb 05, 2020@11:38:37PM -0800, Fangrui Song wrote: > > > ## Different sh_entsize > > > > > > .section .foo,"aM",@progbits,4 > > > .section .foo,"aM",@progbits,8 > > > > > > GNU as emits a warning `Warning: ignoring changed section entity size for .foo` > > > > I think this one probably should be an error rather than a warning. > > An error is fine, but it can bring up some implementation difficulties. > If an implementation does a one-pass scan over global variables to > emit .section directives and variable labels, it may not know sh_entsize > when it is about the emit the first .section directive. > > > > The output sh_entsize is 4. If the second .section defines an object, the object may get corrupted after merging > > > (https://bugs.llvm.org/show_bug.cgi?id=43457 ) > > > For this case, we have several choices: > > > > > > 1. (Status quo) Emit one section. Set sh_entsize to 4 and emit a warning. > > > 2. Emit two sections, i.e. sh_entsize is a differentiator. > > > > If you do, the linker won't do merging of values for those sections. > > > > > 3. Emit one section. Set sh_entsize to 0. Should the assembler emit a warning? > > > > And remove SHF_MERGE too I guess. That's an option but I think it's > > better just to error. > > > > > > > > ## Different sh_flags > > > > > > .section .foo,"aw" > > > .section .foo,"a" # Warning: ignoring changed section attributes for .foo > > > > > > Shall we emit two sections? > > > > I don't think so. User assembly often gets section attributes wrong > > or leaves them off entirely for special sections known to the > > assembler. ie. the first .section .foo above is a built-in rather > > than user input. > > > > > > > > ## Different sh_type > > > > > > .section .foo,"a",@progbits > > > .section .foo,"a",@nobits # Warning: ignoring changed section type for .foo > > > > > > Shall we emit two sections? > > > > Again we should continue to handle the case where .foo is a special > > section of known type. So I think a warning rather than creating two > > sections is appropriate. > > Do you think the warnings should be upgraded to errors (for sh_flags and > sh_type)? No. -- Alan Modra Australia Development Lab, IBM