From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 287713858D20 for ; Wed, 9 Aug 2023 08:10:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 287713858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id F3B501F747; Wed, 9 Aug 2023 08:10:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1691568615; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Sm+9fSP1c1sLA8Xszr0a5aaH+fyB375WB3dac97UtGg=; b=wVXvkyOGnAg/YRm7ozQevNGZU9hzqqhcsZrs2sJZROamvCn+u/BfVSYlt8A1hWPDDmUGXf KqC/S77QWw3UeE22rxS37MUd/mjPmaqHZTVXkCG6/K4gId0sIx3+tgeKg0Ynxzl2eDupR8 Dgb7/ieseXIt7Sd3C2Z+TMhhShZ5RWA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1691568615; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Sm+9fSP1c1sLA8Xszr0a5aaH+fyB375WB3dac97UtGg=; b=n1dJAyqsLYLNwONledGfttS2prS3jJVa6NsGvtc7vrC1DOU6RZDWEMvyq3YB7q/Gs8pacr qzRAKhgs6VbwK+Bg== Received: from hawking.nue2.suse.org (unknown [10.168.4.11]) by relay2.suse.de (Postfix) with ESMTP id E5EB52C142; Wed, 9 Aug 2023 08:10:14 +0000 (UTC) Received: by hawking.nue2.suse.org (Postfix, from userid 17005) id C316E4AAD48; Wed, 9 Aug 2023 10:10:14 +0200 (CEST) From: Andreas Schwab To: Palmer Dabbelt Cc: binutils@sourceware.org Subject: Re: [PATCH] Add basic support for RISC-V 64-bit EFI objects In-Reply-To: (Palmer Dabbelt's message of "Tue, 08 Aug 2023 18:54:34 -0700 (PDT)") References: X-Yow: I FORGOT to do the DISHES!! Date: Wed, 09 Aug 2023 10:10:14 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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."