From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Teddy Astie <teddy.astie@vates.tech>,
Marek Marczykowski <marmarek@invisiblethingslab.com>,
Daniel Smith <dpsmith@apertussolutions.com>,
Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi
Date: Wed, 17 Jun 2026 12:53:23 +0200 [thread overview]
Message-ID: <ajJ8o2U3Gn3zwjqt@macbook.local> (raw)
In-Reply-To: <a307207f-7cf2-40fb-927f-bbaa841b94ba@suse.com>
On Wed, Jun 17, 2026 at 12:37:38PM +0200, Jan Beulich wrote:
> On 17.06.2026 12:29, Roger Pau Monné wrote:
> > On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote:
> >> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
> >> yet we need to access it ourselves when switching out of "physical mode".
> >> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
> >> doesn't have the discardable flag set (which cannot even be expressed in
> >> ELF) will yield the output section also non-discardable.
> >>
> >> Since for intermediate binaries we don't care about section attributes,
> >> link in the new object only on the final linking pass.
> >
> > I'm not sure I follow. Xen already does generate a custom .reloc
> > section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using
> > the mkreloc utility, and hence the .reloc section should never be
> > marked as discardable?
>
> mkreloc is used only when we recognize the linker to be incapable of
> producing (correct) base relocations. As a modern linker is required for
> the desired IMAGE_SCN_MEM_DISCARDABLE handling for .reloc, mkreloc
> wouldn't normally be used there. Hence no .reloc section with the wanted
> property.
I see, MKRELOC becomes ":" then, I didn't catch that.
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Thanks, Roger.
next prev parent reply other threads:[~2026-06-17 10:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 16:17 [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi Jan Beulich
2026-06-17 10:29 ` Roger Pau Monné
2026-06-17 10:37 ` Jan Beulich
2026-06-17 10:53 ` Roger Pau Monné [this message]
2026-06-17 11:20 ` Andrew Cooper
2026-06-17 11:44 ` Jan Beulich
2026-06-17 10:56 ` Oleksii Kurochko
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=ajJ8o2U3Gn3zwjqt@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dpsmith@apertussolutions.com \
--cc=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.com \
--cc=oleksii.kurochko@gmail.com \
--cc=teddy.astie@vates.tech \
--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.