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:29:31 +0200 [thread overview]
Message-ID: <ajJ3C40FLsyBZn-U@macbook.local> (raw)
In-Reply-To: <652b57e0-42f8-47c8-b94d-df862874aba3@suse.com>
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?
Thanks, Roger.
next prev parent reply other threads:[~2026-06-17 10:30 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é [this message]
2026-06-17 10:37 ` Jan Beulich
2026-06-17 10:53 ` Roger Pau Monné
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=ajJ3C40FLsyBZn-U@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.