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

[Michael Matz]

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).

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.