[PATCH] RISC-V: Add support for RISCV64 EFI(efi-*-riscv64)

[Palmer Dabbelt]

On Mon, 28 Nov 2022 07:08:05 PST (-0800), jiawei@iscas.ac.cn wrote:
>
>
>
> > -----原始邮件-----
> > 发件人: "Jan Beulich" <jbeulich@suse.com>
> > 发送时间: 2022-11-28 15:50:12 (星期一)
> > 收件人: jiawei <jiawei@iscas.ac.cn>
> > 抄送: 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
> > 主题: Re: [PATCH] RISC-V: Add support for RISCV64 EFI(efi-*-riscv64)
> > 
> > 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).
>
> Thanks for your comments, you are right, I think this only a partial 
>
> implement for efistub support: 
>
> https://man.archlinux.org/man/core/systemd/linuxaa64.efi.stub.7.en

I'm not exactly sure what's going on here, but at least in Linux we can 
already produce integrated EFI stubs by putting a fake PE header into 
flat binaries.  That's very much a hack, but it sounds like this target 
would have all the same issues?

I suppose there's some use case for these fake-PE binaries as we're 
producing them from Linux, but as pointed out they're pretty fragile.  
I'm not sure it's a net benefit to have a target that generates them -- 
I guess if this errors out when trying to generate any PE it can't 
handle then at least there's some protection from users shooting 
themselves in the foot, but I haven't read the code in enough detail to 
know that's the case.

That said, it seems entirely sane to just wait for a full PE 
implementation before merging the code.

> > 
> > > 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
>
> Yes, it just mean it can verify with using objdump. Added a testcase to verify
> that if we can use target 'pei-riscv'.
>
>
> </jiawei@iscas.ac.cn></jbeulich@suse.com>