Re: [PATCH v1 0/7 SECTOR: Support aligning to flash sector boundary

[Ulf Samuelsson <binutils@emagii.com>]

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.