From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=RWcB=7F=emagii.com=binutils@sourceware.org>
Received: from emagii.se (www.emagii.com [185.133.207.17])
	by sourceware.org (Postfix) with ESMTPS id 931693858D1E
	for <binutils@sourceware.org>; Mon, 13 Mar 2023 15:29:51 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 931693858D1E
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=emagii.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emagii.com
Received: from [10.175.196.145] (84-55-68-216.customers.ownit.se [84.55.68.216])
	by emagii.se (Postfix) with ESMTPSA id F283812001D;
	Mon, 13 Mar 2023 16:29:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com;
	s=default; t=1678721389;
	bh=J+G40uVBB7lRQjgRtmZd4HscfvwLq6lhg2XPXOpfaEY=; h=Subject:To:From;
	b=rgMKtQy0l6TKmgutnIrXZ3O4IGdoJRS23IO564VMfJRsilf5MHPEzyv5GMph84MRj
	 PKz1yT7dztCBwxYIqHDPP/pUXWzH6beJiFYGXG0VAAO4GjobCf5GMM1vhxGXPgwzTz
	 oQowg6d8IJF/3NgFGAsbxRShivPrEvS7mdewS3gI=
Authentication-Results: emagii.beebytevps.io;
        spf=pass (sender IP is 84.55.68.216) smtp.mailfrom=binutils@emagii.com smtp.helo=[10.175.196.145]
Received-SPF: pass (emagii.beebytevps.io: connection is authenticated)
Message-ID: <662cb2c6-e42d-4d46-3978-7159e86d88e5@emagii.com>
Date: Mon, 13 Mar 2023 16:29:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [PATCH v1 0/7 SECTOR: Support aligning to flash sector boundary
Content-Language: en-US
To: Michael Matz <matz@suse.de>
Cc: binutils@sourceware.org, nickc@redhat.com
References: <alpine.LSU.2.20.2303101722270.16810@wotan.suse.de>
 <95D14810-3DEE-44ED-B071-72BC8C3C3AC0@emagii.com>
 <alpine.LSU.2.20.2303131308020.16810@wotan.suse.de>
From: Ulf Samuelsson <binutils@emagii.com>
In-Reply-To: <alpine.LSU.2.20.2303131308020.16810@wotan.suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-PPP-Message-ID: 
 <167872138731.3694602.2871534458718303675@localhost.localdomain>
X-PPP-Vhost: emagii.com
X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_FAIL,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <binutils.sourceware.org>


On 2023-03-13 14:12, Michael Matz wrote:
> Hello,
>
> On Fri, 10 Mar 2023, Ulf Samuelsson wrote:
>
>> Since the proposal defines the begin, end and size of a sector as symbols,
>> you can do already today.
>> . = ALIGN(”bank00#04#size”).
>> Right now, the symbols are defined late, but that is easily changed.
> You argued that one point of you introducing the ALLOCATE_SECTOR directive
> was that it naturally dependend on dot, exactly so that the user does
> _not_ have to deal with the artificial names.
>
> So, a builtin function (however implemented) that actually gets you that
> very size for a given address makes the most sense IMHO.

Not really. The proposal is to avoid having to figure out the boundaries 
for each sector.
and to avoid having to maintain files which aligns to the sector.

But I tried implementing

   . = ALIGN(SECTOR);

and that works now.

If "." is within a sector, then it moves "." to beyond the sector,
otherwise it remains as it is.

While

   . = ALIGN(SECTOR("."));

allows you to get the sector for any address, what would be a reasonable 
motivation for having this?

To me, it just adds additional ways of introducing errors by increased 
complexity in the syntax.


Best Regards
Ulf Samuelsson

> Ciao,
> Michael.