Re: [PATCH] Add basic support for RISC-V 64-bit EFI objects

[Andreas Schwab <schwab@suse.de>]

On Aug 08 2023, Palmer Dabbelt wrote:

> So the idea is to just objcopy an ELF into a PE for EFI?  IIUC that's
> generally the way to go for this sort of thing.  In Linux we just have a
> PE header manually embedded in a flat binary, but presumably EFI folks
> want to have objcopy support for some reason?

My main intention is to let BFD recognize EFI objects so that I can
objdump them easily.  The support for objcopy comes in naturally, and
some packages do use objcopy to create EFI objects from ELF (on archs
where BFD supports it).

> Is the idea that anyone who wants EFI also wants 64-bit?

That's not my intention.  It's just that I have no 32-bit setup for
testing.

>> binutils:
>> 	* testsuite/binutils-all/loongarch64/pei-riscv64.d: New.
>> 	* testsuite/binutils-all/loongarch64/pei-riscv64.s: New.
>
> I think those paths are wrong?

Yes, that reveals where I copied the whole thing from. ;-)

>> diff --git a/include/coff/pe.h b/include/coff/pe.h
>> index 6b26d533218..dd4cf547a77 100644
>> --- a/include/coff/pe.h
>> +++ b/include/coff/pe.h
>> @@ -156,6 +156,8 @@
>>  #define IMAGE_FILE_MACHINE_R10000            0x0168
>>  #define IMAGE_FILE_MACHINE_R3000             0x0162
>>  #define IMAGE_FILE_MACHINE_R4000             0x0166
>> +#define IMAGE_FILE_MACHINE_RISCV32           0x5032
>> +#define IMAGE_FILE_MACHINE_RISCV64           0x5064
>
> The spec has rv128 as well, but I guess nothing's supporting that so it
> doesn't really matter?

I don't think we will see any 128-bit CPU of any kind any time soon.

>> +#define	RISCV64MAGIC	0x5064  /* From Microsoft specification. */
>
> Which is the same as IMAGE_FILE_MACHINE_RISCV64, not sure if we can use
> that here though?

I think the intention is to separate the PE stuff from the COFF base.

>> +/* We use the .rdata section to hold read only data.  */
>> +#define _LIT	".rdata"
>
> Is that a PE-ism?  It's ".rodata" elsewhere in RISC-V.  It looks like the
> other PE/COFF ports are ".rdata", though.

.rdata seems to be a normal PE/COFF thing.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."