"correct" way to generate EFI binaries?

[Palmer Dabbelt]

On Fri, 10 Jul 2020 16:08:38 PDT (-0700), Jim Wilson wrote:
> On Wed, Jul 8, 2020 at 10:33 AM Jim Wilson <jimw@sifive.com> wrote:
>> On Wed, Jul 8, 2020 at 10:23 AM Alexander von Gluck IV
>> <kallisti5@unixzen.com> wrote:
>> > > riscv64 ( no Pe in bfd :-( )
>>
>> I know that some work was done on this, but I don't know if it was
>> finished, I don't know if they have copyright assignments, and I've
>> never seen patches.  If they do exist, they are probably somewhere in
>> the edkii (aka edk2) source tree.
>> https://riscv.org/wp-content/uploads/2016/01/Tues1415-RISC-V-and-UEFI.pdf
>
> I just found this while looking for something else.
>     https://github.com/riscv/riscv-uefi-edk2-docs
> This has binaries for a x86_64-linux cross riscv64 toolchain that
> contains UEFI support.  I've never tried any of this stuff myself.

IIRC they had some tool that converts ELF to PE for the UEFI stuff.  We do
something pretty simple in Linux where we objdump a flat binary with the PE
header just written in assembly at the start (well, not quite yet -- we're
actively not setting the PE magic bits as we don't quite have EFI yet).

If you want the combined PE/flat binaries then you need the C extension, as we
rely on the PE magic number also being a valid instruction (the next
instruction jumps past the rest of the header).  If you only want PE binaries
then you should be able to generate them for any ISA, but in Linux we intend on
relying on a single binary being both PE and flat so it can run on any
bootloader.

It's obviously far from a general solution, but if you have control over the
software then it can work as long as you're careful.  We didn't invent the
scheme, it's from arm64 (and IIRC to a lesser extent event Intel).

Not sure what the original question was, though, so I don't know if that helps
any :)