From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by sourceware.org (Postfix) with ESMTPS id 084A23938808 for ; Thu, 12 Mar 2020 02:55:29 +0000 (GMT) Received: by mail-pf1-f182.google.com with SMTP id z5so2480344pfn.5 for ; Wed, 11 Mar 2020 19:55:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rThPAvts1aVr6HyXRRp6UwSFVxhuxFZx5aG4tAEsMtA=; b=JCZ85qDfyGYT1HdRAeWqaOYMUdYEi9QPc4zF4cf7aDFNwnZsD6g0tsiWUeLaJpr4/c vmEirJtlk3Ex84sFLfqYNpFkHN3QKCDGZQkvLq1AHqUrOG0vE130nMtaTzJ0rYMoDcr8 0iw+pQzxyJhDDOTScfUjENyhDinSbFzWEUJ5xMXvy6oA3SkCwGbzYEUV0echeZ3BRThU +yDKf5ZydsjaFMWos14M1lsm4XzYbphady/JScZkGqAGFqz8pnTVbGJfEpuPzamqJP4S maRiolD+/Le2wjneStXCe2DgbxsqpM4Wd2DnZY7YaZn0M4C9aDjdcoK6NLqqkV7wJmVq jHoQ== X-Gm-Message-State: ANhLgQ2b1U1Q0G1ZRyLnSZa8T3W6w9Cop4gDs6j0qM0Nt6+qIvgfYAKq eLGERaci5q3kFJZMjLpiFV3gY6hH X-Google-Smtp-Source: ADFU+vvlkwbKE0Nh4vSdyzedm1v8NMqCtR+15Tz50UNRMsOfazHY3zPjarsn9b0RGIGKKeFEAyBkEA== X-Received: by 2002:aa7:82ce:: with SMTP id f14mr6028878pfn.167.1583981728216; Wed, 11 Mar 2020 19:55:28 -0700 (PDT) Received: from localhost ([2601:647:4b01:ae80::51fb]) by smtp.gmail.com with ESMTPSA id d5sm46889654pga.36.2020.03.11.19.55.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2020 19:55:27 -0700 (PDT) Date: Wed, 11 Mar 2020 19:55:26 -0700 From: Fangrui Song To: Alan Modra Cc: binutils@sourceware.org Subject: Re: ld: output section alignment and empty section. Message-ID: <20200312025526.epilggawistqy54l@google.com> References: <20200310064225.GT5384@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200310064225.GT5384@bubble.grove.modra.org> X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 02:55:29 -0000 On 2020-03-10, Alan Modra wrote: >On Thu, Mar 05, 2020 at 02:55:44PM +0100, KONRAD Frederic wrote: >> Hi, >> >> I just figured out that the following linker script hunk: >> >> . = ALIGN(0x4); >> .rodata : >> { >> . = ALIGN(0x4); >> } >> >> is creating an empty .rodata output section while I was expecting it not to be >> emited. >> >> This is because we flag ". = ALIGN(xxx)" as SEC_KEEP in exp_fold_tree_1. >> >> Dropping that for ". = ALIGN(constant)" seems to fix the behavior: > >Yes it would, but you could also write the align inside .rodata using > > . = ALIGN(. != 0 ? 4 : 1); > >That is one of the few forms of assigning to dot that ld recognises as >*not* resulting in "keep this section". This is documented under node >"Output Section Discarding" in ld.info. > >I don't think there is a good reason to change this behaviour as there >may even be scripts that rely on a simpler ALIGN to keep the section. > >> Is that because strip_excluded_output_sections happens before the relaxation? >> Could that be a problem in the case of a constant alignment? > >Yes and yes. It is possible to create a script that assigns an >address (before the colon in an output section statement) or alignment >(after the colon) to a section less than the constant alignment in >some ". = ALIGN();" statement in that section, and the addresses of >prior sections conspire to make the alignment do nothing before >relaxation but to add padding when prior sections change. The patches >that were reverted with e0a3af227e ran into something like that when I >tried to make the single operand ALIGN behave like the two operand >form. > >> What do you think? > >Fix your script. :-) So the rule is: SECTIONS { .not_created : { . = ALIGN(. != 0 ? 4 : 1); } .created : { . = ALIGN(4); } } I think it'd be nice to simply make the two output section descriptions create empty sections. SECTIONS { .not_created : { PROVIDE(unreferenced = .); } .created0 : { . = ALIGN(. != 0 ? 4 : 1); } .created1 : { . = ALIGN(4); } .created2 : { PROVIDE(referenced = .); } }