From: Alan Modra <amodra@gmail.com>
To: Fangrui Song <i@maskray.me>
Cc: binutils <binutils@sourceware.org>, smithp352@googlemail.com
Subject: Re: [ld] section address : ALIGN(align) and the maximum of input section alignments
Date: Wed, 04 Mar 2020 08:04:00 -0000 [thread overview]
Message-ID: <20200304080414.GW5384@bubble.grove.modra.org> (raw)
In-Reply-To: <BY5PR07MB731630D51C5AAF3583B5BC86CBE50@BY5PR07MB7316.namprd07.prod.outlook.com>
On Tue, Mar 03, 2020 at 10:39:45PM -0800, Fangrui Song wrote:
> The implementation is complex. For users to understand, I think it
> will be helpful to have something more detailed in
> https://sourceware.org/binutils/docs/ld/Output-Section-Address.html#Output-Section-Address
>
> If my understanding is correct
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=233bf4f847b136705247e2f7f11bae41c72448a4
> makes the output section address override sh_addralign computed from
> the maximum of input section alignments.
Right.
> So, generally the rules are:
> * The max of ALIGN and (the maximum of input section alignments) is taken.
> * The output section address overrides the above. If sh_addr %
> alignment != 0, set sh_addralign to the largest alignment that makes
> sh_addr%alignment=0
> In this case, should the linker emit a warning?
I don't think so. The input sections are still aligned within the
output section to their required alignment.
> * ALIGN and the output section address cannot be specified at the same
> time. This is considered a linker script "undefined behavior". Users
> should not rely on a particular result.
I'm not going to make that change for ld.bfd. I said it probably
would have been better if ALIGN for output section statements hadn't
been invented, but once there are users for a script feature it can't
be removed without a good reason.
> --warn-section-align may be out of place. It can be noisy for normal
> output section descriptions like .foo : ALIGN(16) { ... } without
> a preceding dot advancing to a multiple of 16.
It's even more noisy when relaxation is enabled..
--
Alan Modra
Australia Development Lab, IBM
next prev parent reply other threads:[~2020-03-04 8:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 5:23 Fangrui Song
2020-02-26 6:31 ` Fangrui Song
2020-03-03 5:46 ` Fangrui Song
2020-03-03 22:39 ` Alan Modra
2020-03-04 0:03 ` Fangrui Song
[not found] ` <BY5PR07MB7316674DD98011D2AD812A63CBE40@BY5PR07MB7316.namprd07.prod.outlook.com>
2020-03-04 5:56 ` Alan Modra
2020-03-04 6:40 ` Fangrui Song
2020-03-04 8:04 ` Alan Modra [this message]
2020-03-05 6:41 ` Fangrui Song
2020-03-05 11:21 ` Alan Modra
2020-03-10 19:00 ` Fangrui Song
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=20200304080414.GW5384@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=i@maskray.me \
--cc=smithp352@googlemail.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).