From: Jan Beulich <jbeulich@suse.com>
To: jiawei <jiawei@iscas.ac.cn>
Cc: nelson@rivosinc.com, kito.cheng@sifive.com, palmer@rivosinc.com,
christoph.muellner@vrull.eu, philipp.tomsich@vrull.eu,
felixonmars@archlinux.org, wuwei2016@iscas.ac.cn,
binutils@sourceware.org
Subject: Re: [PATCH] RISC-V: Add support for RISCV64 EFI(efi-*-riscv64)
Date: Mon, 28 Nov 2022 08:50:12 +0100 [thread overview]
Message-ID: <c6532efc-9321-0cc0-439a-e77b3e08e042@suse.com> (raw)
In-Reply-To: <20221128063532.1153605-1-jiawei@iscas.ac.cn>
On 28.11.2022 07:35, jiawei wrote:
> This adds support for efi-*-riscv64 by virtue of adding a new PEI target pei-
> riscv64. This is not a full target and only exists to support EFI at
> this time.
Just some general remarks below; I haven't looked at the changes
themselves, yet (and I also can't promise I would get to doing so any
time soon).
> This means that this target does not support relocation processing and is mostly
> a container format. This format has been added to elf based riscv64 targets
> such that efi images can be made natively on Linux.
Hmm, I have reservations (not just for RISC-V) against this objcopy-only
model. It would imo be better if ld was made capable of producing EFI
binaries (and then likely also other PE ones) from ELF input, like is
possible for at least some other targets (e.g. x86).
Furthermore I also question the usefulness of conversion without reloc
handling. This may help with images built into firmware, but anything
you can load at runtime may not be loadable at all if the address range
it was linked for is occupied or otherwise unavailable, and if the
image cannot be relocated because relocations were stripped (and the
image is marked accordingly).
> However this target is not valid for use with gas but only with objcopy.
I guess you mean ld, not gas here? PE is an executable file format after all,
not an object file one. It would be COFF there ...
Jan
next prev parent reply other threads:[~2022-11-28 7:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 6:35 jiawei
2022-11-28 7:50 ` Jan Beulich [this message]
2022-11-28 15:08 ` jiawei
2022-11-28 17:48 ` Palmer Dabbelt
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=c6532efc-9321-0cc0-439a-e77b3e08e042@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=christoph.muellner@vrull.eu \
--cc=felixonmars@archlinux.org \
--cc=jiawei@iscas.ac.cn \
--cc=kito.cheng@sifive.com \
--cc=nelson@rivosinc.com \
--cc=palmer@rivosinc.com \
--cc=philipp.tomsich@vrull.eu \
--cc=wuwei2016@iscas.ac.cn \
/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).