From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78867 invoked by alias); 5 Mar 2020 11:21:32 -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 78859 invoked by uid 89); 5 Mar 2020 11:21:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.9 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=decreased, H*Ad:D*googlemail.com, a.s, data.rel.ro,"aw X-HELO: mail-pg1-f195.google.com Received: from mail-pg1-f195.google.com (HELO mail-pg1-f195.google.com) (209.85.215.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Mar 2020 11:21:29 +0000 Received: by mail-pg1-f195.google.com with SMTP id u12so2608296pgb.10 for ; Thu, 05 Mar 2020 03:21:29 -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=NAfTfdNiH3q4L560s0NXJBipuzHvGZfZzEyRfmWFV9Q=; b=GZ4g/eqlHuUbFxgeBQot7XLh1lfDwNjW+uXuDOPepXoNJ1cdKNxjJrIwrrjeWL88eg 8JM7DxWdymnvx+eInH6W288FbUy5ndp8OeKuRb0XEdfRBWih7T0Z2IHW5jz9VgBAF7/B Qbtgqr412ZvcPJljtZeCFjfchjMJNmUf+F+BqilXky5zc8BzCs5KXfeLG95bHNwgH8Zr 3gtJfQedj4kD5rQ0hsu1lkupA9+FYv/QLX9aeKqbjlaILci8Dudc6BFab0C8u1LpjHeV WjBQB1LFqsgNK9Krlw+0fUj6cBHKary26ciRmn8zWrTzZl7xFjdtklqb9Kqm8WkCwL9F ltMQ== 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 mp5sm5855862pjb.48.2020.03.05.03.21.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2020 03:21:26 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id C1F6580E20; Thu, 5 Mar 2020 21:51:22 +1030 (ACDT) Date: Thu, 05 Mar 2020 11:21:00 -0000 From: Alan Modra To: Fangrui Song Cc: binutils , smithp352@googlemail.com Subject: Re: [ld] section address : ALIGN(align) and the maximum of input section alignments Message-ID: <20200305112122.GB5384@bubble.grove.modra.org> 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> <20200305064128.ko2qvtxwti3ckvt7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200305064128.ko2qvtxwti3ckvt7@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00118.txt On Wed, Mar 04, 2020 at 10:41:28PM -0800, Fangrui Song wrote: > 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) I'm not going to do that for BFD ld. The user chose an address for an output section, and all input sections are placed in that section according to their alignment. No warning needed, just a change in sh_addralign calculation. I'll note that ld could quite correctly set sh_addralign to 0 or 1 for any final linked executable. > > > --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 < .globl _start; _start: ret > .section .data.rel.ro,"aw"; .balign 8; .byte 0 > .data; .byte 0 > .section .data2,"aw"; .balign 8; .byte 0 > .bss; .balign 32; .byte 0 > e > as a.s -o a.o > > % ./ld-new a.o -o a --warn-section-align ./ld-new: warning: start > of section .got changed by 7 > ./ld-new: warning: start of section .got.plt changed by 7 > ./ld-new: warning: start of section .data2 changed by 6 > ./ld-new: warning: start of section .bss changed by 23 > ./ld-new: warning: start of section .data.rel.ro changed by 4088 > ./ld-new: warning: start of section .got changed by 4088 > ./ld-new: warning: start of section .got.plt changed by 4088 > ./ld-new: warning: start of section .data2 changed by 4096 > ./ld-new: warning: start of section .bss changed by 4096 > ./ld-new: warning: start of section .rela.dyn changed by 56 > ./ld-new: warning: start of section .rela.plt changed by 56 > ./ld-new: warning: start of section .data.rel.ro changed by -4088 > ./ld-new: warning: start of section .got changed by -4088 > ./ld-new: warning: start of section .got.plt changed by -4088 > ./ld-new: warning: start of section .data2 changed by -4096 > ./ld-new: warning: start of section .bss changed by -4096 > ./ld-new: warning: start of section .data.rel.ro changed by 4088 > ./ld-new: warning: start of section .got changed by 4088 > ./ld-new: warning: start of section .got.plt changed by 4088 > ./ld-new: warning: start of section .data2 changed by 4096 > ./ld-new: warning: start of section .bss changed by 4096 > > This also demonstrates how annoying --warn-section-align can be. PR 25570 * ldlang.c (lang_size_sections_1): Don't report changes on second and subsequent iterations that make no change in alignment from that already reported. diff --git a/ld/ldlang.c b/ld/ldlang.c index 6ffa7af575..63f9d182ea 100644 --- a/ld/ldlang.c +++ b/ld/ldlang.c @@ -5597,7 +5597,13 @@ lang_size_sections_1 if (lang_sizing_iteration == 1) diff = dotdelta; else if (lang_sizing_iteration > 1) - diff = newdot - os->bfd_section->vma; + { + /* Only report adjustments that would change + alignment from what we have already reported. */ + diff = newdot - os->bfd_section->vma; + if (!(diff & (((bfd_vma) 1 << section_alignment) - 1))) + diff = 0; + } if (diff != 0 && (config.warn_section_align || os->addr_tree != NULL)) -- Alan Modra Australia Development Lab, IBM