public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ulf Samuelsson <binutils@emagii.com>
To: Michael Matz <matz@suse.de>
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 16:29:43 +0100	[thread overview]
Message-ID: <662cb2c6-e42d-4d46-3978-7159e86d88e5@emagii.com> (raw)
In-Reply-To: <alpine.LSU.2.20.2303131308020.16810@wotan.suse.de>


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.

  reply	other threads:[~2023-03-13 15:29 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 [this message]
2023-03-13 15:54             ` Michael Matz
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=662cb2c6-e42d-4d46-3978-7159e86d88e5@emagii.com \
    --to=binutils@emagii.com \
    --cc=binutils@sourceware.org \
    --cc=matz@suse.de \
    --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).