From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114231 invoked by alias); 5 Mar 2020 06:41:34 -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 114223 invoked by uid 89); 5 Mar 2020 06:41:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*Ad:D*googlemail.com, HX-Spam-Relays-External:209.85.215.194, H*RU:209.85.215.194, H*r:4b01 X-HELO: mail-pg1-f194.google.com Received: from mail-pg1-f194.google.com (HELO mail-pg1-f194.google.com) (209.85.215.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Mar 2020 06:41:31 +0000 Received: by mail-pg1-f194.google.com with SMTP id d9so2269419pgu.3 for ; Wed, 04 Mar 2020 22:41:31 -0800 (PST) Return-Path: Received: from localhost ([2601:647:4b01:ae80::51fb]) by smtp.gmail.com with ESMTPSA id 6sm14999239pfx.32.2020.03.04.22.41.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2020 22:41:29 -0800 (PST) Date: Thu, 05 Mar 2020 06:41:00 -0000 From: Fangrui Song To: Alan Modra Cc: binutils , smithp352@googlemail.com Subject: Re: [ld] section address : ALIGN(align) and the maximum of input section alignments Message-ID: <20200305064128.ko2qvtxwti3ckvt7@gmail.com> References: <20200226052300.wazzfmivxta63vef@gmail.com> <20200226063003.4uvshiarho3wbkrl@google.com> <20200303223901.GO5384@bubble.grove.modra.org> <20200304055641.GT5384@bubble.grove.modra.org> <20200304080414.GW5384@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200304080414.GW5384@bubble.grove.modra.org> X-SW-Source: 2020-03/txt/msg00115.txt For convenience, I will use some notations: max_input_align: maximum of input section alignments. addr_tree: output section address On 2020-03-04, Alan Modra wrote: >On Tue, Mar 03, 2020 at 10:39:45PM -0800, Fangrui Song wrote: >> The implementation is complex. For users to understand, I think it >> will be helpful to have something more detailed in >> https://sourceware.org/binutils/docs/ld/Output-Section-Address.html#Output-Section-Address >> >> If my understanding is correct >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=233bf4f847b136705247e2f7f11bae41c72448a4 >> makes the output section address override sh_addralign computed from >> the maximum of input section alignments. > >Right. > >> So, generally the rules are: >> * The max of ALIGN and (the maximum of input section alignments) is taken. >> * The output section address overrides the above. If sh_addr % >> alignment != 0, set sh_addralign to the largest alignment that makes >> sh_addr%alignment=0 >> In this case, should the linker emit a warning? > >I don't think so. The input sections are still aligned within the >output section to their required alignment. > >> * ALIGN and the output section address cannot be specified at the same >> time. This is considered a linker script "undefined behavior". Users >> should not rely on a particular result. > >I'm not going to make that change for ld.bfd. I said it probably >would have been better if ALIGN for output section statements hadn't >been invented, but once there are users for a script feature it can't >be removed without a good reason. I take ALIGN as a way to overalign an output section. When ALIGN < max_input_align, do we agree that sh_addralign = max(ALIGN, max_input_align) = max_input_align ? When both addr_tree and ALIGN are specified (what I called "undefined behavior"), and addr_tree is misaligned, sh_addralign can be decreased from max(ALIGN,max_input_align) to (addr_tree|max(ALIGN,max_input_align)) & -(addr_tree|max(ALIGN,max_input_align)) Commit 233bf4f847b136705247e2f7f11bae41c72448a4 is made so that "The value of sh_addr must be congruent to 0, modulo the value of sh_addralign." is obeyed. Another view is that the user intentionally breaks the ELF rule. We can keep sh_addralign as max(ALIGN,max_input_align) and emit a warning along the line of: warning: address (0x10010) of section .foo is not a multiple of alignment (32) >> --warn-section-align may be out of place. It can be noisy for normal >> output section descriptions like .foo : ALIGN(16) { ... } without >> a preceding dot advancing to a multiple of 16. /* Without this assignment, the ALIGN(16) below will likely report a warning */ . = ALIGN(16); .foo : ALIGN(16) { ... } Does this suggest that --warn-section-align is not very useful? Keep reading. >It's even more noisy when relaxation is enabled.. https://sourceware.org/ml/binutils/2020-03/msg00107.html does not fix the --warn-section-align version of PR25570. # My original example. cat > a.s <