From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
<xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 1/2] xen/build: put image header into a separate section
Date: Tue, 8 Mar 2022 17:36:32 +0100 [thread overview]
Message-ID: <YieGEMpcSl+qdZ1e@Air-de-Roger> (raw)
In-Reply-To: <8f37e018-ab41-3e4d-14c7-1a25aa35e958@suse.com>
On Tue, Mar 08, 2022 at 04:08:53PM +0100, Jan Beulich wrote:
> On 08.03.2022 15:18, Roger Pau Monné wrote:
> > On Tue, Mar 08, 2022 at 02:57:23PM +0100, Jan Beulich wrote:
> >> On 08.03.2022 14:49, Roger Pau Monne wrote:
> >>> So it can be explicitly placed ahead of the rest of the .text content
> >>> in the linker script (and thus the resulting image). This is a
> >>> prerequisite for further work that will add a catch-all to the text
> >>> section (.text.*).
> >>>
> >>> Note that placement of the sections inside of .text is also slightly
> >>> adjusted to be more similar to the position found in the default GNU
> >>> ld linker script.
> >>>
> >>> The special handling of the object file containing the header data as
> >>> the first object file passed to the linker command line can also be
> >>> removed.
> >>>
> >>> While there also remove the special handling of efi/ on x86. There's
> >>> no need for the resulting object file to be passed in any special
> >>> order to the linker.
> >>>
> >>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> >>
> >> Looks good to me, but I have one question before feeling ready to
> >> offer R-b:
> >>
> >>> @@ -86,8 +84,13 @@ SECTIONS
> >>> *(.text.kexec) /* Page aligned in the object file. */
> >>> kexec_reloc_end = .;
> >>>
> >>> - *(.text.cold)
> >>> - *(.text.unlikely)
> >>> + *(.text.cold .text.cold.*)
> >>> + *(.text.unlikely .text.*_unlikely .text.unlikely.*)
> >>
> >> What generates .text.*_unlikely? And if anything really does, why
> >> would .text.cold not have a similar equivalent?
> >
> > That matches what I saw in the default linker script from my version
> > of GNU ld:
> >
> > *(.text.unlikely .text.*_unlikely .text.unlikely.*)
> >
> > I really don't know what could generate .text.*_unlikely, but since
> > it's part of the default linker script I assumed it was better to just
> > add it.
>
> I've checked - gcc up to 4.5.x would generate .text.*_unlikely; from
> 4.6.x. onwards it would be .text.unlikely.*.
>
> As to the dissimilarity with .text.cold: I wonder why we have that in
> the first place. It matches our __cold attribute, just that we don't
> use that anywhere afaics.
>
> In any event:
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> albeit preferably with .text.cold.* dropped again.
Would you mind dropping the .text.cold.* at commit? Otherwise I can
resend.
Thanks, Roger.
next prev parent reply other threads:[~2022-03-08 16:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-08 13:49 [PATCH v3 0/2] livepatch: enable -f{function,data}-sections compiler option Roger Pau Monne
2022-03-08 13:49 ` [PATCH v3 1/2] xen/build: put image header into a separate section Roger Pau Monne
2022-03-08 13:57 ` Jan Beulich
2022-03-08 14:18 ` Roger Pau Monné
2022-03-08 15:08 ` Jan Beulich
2022-03-08 16:36 ` Roger Pau Monné [this message]
2022-03-08 16:54 ` Jan Beulich
2022-03-08 14:11 ` Andrew Cooper
2022-03-08 14:25 ` Roger Pau Monné
2022-03-08 13:49 ` [PATCH v3 2/2] livepatch: set -f{function,data}-sections compiler option Roger Pau Monne
2022-03-08 14:09 ` Jan Beulich
2022-03-08 14:46 ` Roger Pau Monné
2022-03-08 15:13 ` Jan Beulich
2022-03-08 16:41 ` Roger Pau Monné
2022-03-08 16:58 ` Jan Beulich
2022-03-09 9:30 ` Roger Pau Monné
2022-03-09 10:22 ` Jan Beulich
2022-03-09 19:06 ` Andrew Cooper
2022-03-08 14:52 ` [PATCH v3 0/2] livepatch: enable " Julien Grall
2022-03-09 12:28 ` Roger Pau Monné
2022-03-09 17:01 ` Julien Grall
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=YieGEMpcSl+qdZ1e@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.