public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: Ulf Samuelsson <binutils@emagii.com>
Cc: binutils@sourceware.org, nickc@redhat.com
Subject: Re: [PATCH v1 0/7 SECTOR: Support aligning to flash sector boundary
Date: Mon, 13 Mar 2023 15:54:43 +0000 (UTC)	[thread overview]
Message-ID: <alpine.LSU.2.20.2303131535520.16810@wotan.suse.de> (raw)
In-Reply-To: <662cb2c6-e42d-4d46-3978-7159e86d88e5@emagii.com>

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

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.

  reply	other threads:[~2023-03-13 15:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10  0:08 binutils
2023-03-10  0:08 ` [PATCH v1 1/7] SECTOR: NEWS binutils
2023-03-10  0:08 ` [PATCH v1 2/7] SECTOR: ld.texi binutils
2023-03-10  0:08 ` [PATCH v1 3/7] SECTOR: ldlex.l binutils
2023-03-10  0:08 ` [PATCH v1 4/7] SECTOR: ldgram.y binutils
2023-03-10  0:08 ` [PATCH v1 5/7] SECTOR: language additions binutils
2023-03-10  0:08 ` [PATCH v1 6/7] SECTOR: add testsuite binutils
2023-03-10  0:08 ` [PATCH v1 7/7] SECTOR: Makefile.* binutils
2023-03-10  3:46 ` [PATCH v1 0/7 SECTOR: Support aligning to flash sector boundary Alan Modra
2023-03-10 14:13 ` Michael Matz
2023-03-10 17:01   ` Ulf Samuelsson
2023-03-10 17:30     ` Michael Matz
2023-03-10 17:57       ` Ulf Samuelsson
2023-03-13 13:12         ` Michael Matz
2023-03-13 15:29           ` Ulf Samuelsson
2023-03-13 15:54             ` Michael Matz [this message]
2023-03-13 17:26               ` Ulf Samuelsson
2023-03-13 17:35                 ` Michael Matz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.20.2303131535520.16810@wotan.suse.de \
    --to=matz@suse.de \
    --cc=binutils@emagii.com \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).