From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116281 invoked by alias); 4 Mar 2020 08:04:23 -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 116270 invoked by uid 89); 4 Mar 2020 08:04:23 -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=HX-Received:Wed, H*Ad:D*googlemail.com X-HELO: mail-pl1-f169.google.com Received: from mail-pl1-f169.google.com (HELO mail-pl1-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Mar 2020 08:04:21 +0000 Received: by mail-pl1-f169.google.com with SMTP id d9so663974plo.11 for ; Wed, 04 Mar 2020 00:04:21 -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=8DoTtDTndInj3YdSrO90eWhfgvDcDWS1FeLV4ZSHTZQ=; b=ZlZXCwxTux4K+pqpqGx66jBL7QNNnXTIP2RmpmRVbRDDxG3MLjRSHK2kxVWl81pQmR xq9+4/dx6mRC6B3kTr4dlWqyydrpjCOcPnogUea7crKy/Crypf/xZhd8zHM7+LOUte8H /o1Vv/YLoWoeDI00FUGaC1uoWGyCX0pUdQZ+VzoZ2zC9AQ4aGwZSct1YSDxailYBCtnY hpnxtJq727Ep1Pa4r4NuYbhb+FBowgmpjgjmZ488rp1+0jy3FNtASSKsUiUOcUrKVUnl ErtaIXpmEqSNXTmRp72rrKJEsT6S7yEIVsSt+X9/6yjiM4C57O2MfyebejmbrCqOMxvB lx/w== Return-Path: Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:c198:aaf6:f1b9:1be7]) by smtp.gmail.com with ESMTPSA id y9sm1728121pjj.17.2020.03.04.00.04.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2020 00:04:18 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id A606489FCC; Wed, 4 Mar 2020 18:34:14 +1030 (ACDT) Date: Wed, 04 Mar 2020 08:04: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: <20200304080414.GW5384@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> 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-03/txt/msg00075.txt 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. > --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. It's even more noisy when relaxation is enabled.. -- Alan Modra Australia Development Lab, IBM