From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emagii.se (www.emagii.com [185.133.207.17]) by sourceware.org (Postfix) with ESMTPS id 04F963858D1E for ; Mon, 13 Mar 2023 17:26:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04F963858D1E 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 25EC2120156; Mon, 13 Mar 2023 18:26:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com; s=default; t=1678728400; bh=UatDl5Gl9z7sPh2ZZS8+Iw/G4YMeZgXS96yDLncAJv0=; h=Subject:To:From; b=jwkL+z2Gfj8DdkL8F/Vicbunt3O2NPYh2sgpTvIic2VJYgKg4hf9poLvKSLXE4qsG v+VjPE2tcS8NEH2pTe5vmflN23HVg3rm78u3NdpPaTL0nL3duXReIaf7U51g66uN95 UJTitcLngL9G4AHBlGPYOBK/lJn713GIL12Iuz/0= 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: Date: Mon, 13 Mar 2023 18:26:35 +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 Cc: binutils@sourceware.org, nickc@redhat.com References: <95D14810-3DEE-44ED-B071-72BC8C3C3AC0@emagii.com> <662cb2c6-e42d-4d46-3978-7159e86d88e5@emagii.com> From: Ulf Samuelsson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <167872839919.3782386.9525637712793974487@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: On 2023-03-13 16:54, Michael Matz wrote: > Hello, > > On Mon, 13 Mar 2023, Ulf Samuelsson wrote: > >>> 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? > That doesn't matter so much. The point is that the linker script already > supports an assortment of expressions, one of them 'ALIGN(EXP,ALIGN)' > (with EXP being optional and "dot" by default). This expression can be > used in arbitrary places right now. If it makes sense to use it in > arbitrary places? Probably not, but who knows the future? That's why > syntax extensions to the ldscripts should not necessarily prescribe usage, > and be orthogonal (that was my ultimate reason for suggesting to have > something returning the sector-size for a given address). SECTOR is a function which returns the size of the sector of the current location and can be used to align an expression to that size. You can do ALIGN(exp, SECTOR) if you want to. That will align the expression to the sector size of the current location. So there is no problem with orthogonality. You are asking for a function which does something else. You can add a function (SECTOR_SIZE '(' exp ')') if you find it useful. Best Regards Ulf Samuelsson > > Basically: if we extend the syntax and can give reasonable and obvious > meaning to the new constructs and nevertheless put in limits of usage > right now, then this will eventually bite us in the future: a new usage > turns up, the old syntax doesn't support it, but needs to be maintained > for backward compatibility, and hence another new syntax needs to be > invented that essentially does the same thing as the older syntax that > turned out to be too limited. > >> To me, it just adds additional ways of introducing errors by increased >> complexity in the syntax. > Linkerscripts are a powerful tool, and many of the ways of how to use them > incorrectly are because of too many ad-hoc additions at random syntax > elements over the past decades. But using "FOOBAR(.)" outside an output > section, so that "." isn't defined, and hence could be warned about, is > _not_ a source of much rope to hang yourself. > > > Ciao, > Michael.