RISC-V define the hwcap as same as content of misa, but it only take lower
26-bits.

Signed-off-by: Kito Cheng <kito.cheng@sifive.com>
---
 linux-user/elfload.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 17ab06f612..41b9ef72ea 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1433,6 +1433,17 @@ static void elf_core_copy_regs(target_elf_gregset_t *regs,
 #define ELF_CLASS ELFCLASS64
 #endif
 
+#define ELF_HWCAP get_elf_hwcap()
+
+static uint32_t get_elf_hwcap(void)
+{
+    RISCVCPU *cpu = RISCV_CPU(thread_cpu);
+    /* Take lower 26 bits from misa.  */
+    uint32_t hwcap = cpu->env.misa & 0x3ffffff;
+
+    return hwcap;
+}
+
 static inline void init_thread(struct target_pt_regs *regs,
                                struct image_info *infop)
 {
-- 
2.31.1

On 6/3/21 11:33 PM, Kito Cheng wrote:
> RISC-V define the hwcap as same as content of misa, but it only take lower
> 26-bits.

As far as I can see linux only passes IMAFDC, not all 26 bits.


r~

On Fri, 04 Jun 2021 08:30:30 PDT (-0700), richard.henderson@linaro.org wrote:
> On 6/3/21 11:33 PM, Kito Cheng wrote:
>> RISC-V define the hwcap as same as content of misa, but it only take lower
>> 26-bits.
>
> As far as I can see linux only passes IMAFDC, not all 26 bits.

We decided to play it safe here and only pass through ISA string bits 
that we understood well enough that we could commit to keeping stable 
WRT userspace.  As a concrete example: we now have hardware with an 
implemnetation of v-0.7.1, which is an incompatible draft of the V 
extension.  There's some ambiguity as to whether or not that is a RISC-V 
V extension implenetation, so we're just being careful and avoiding 
passing any of thess bits to userspace.

More importantly: this coorelation between letters and extensions 
doesn't really reflect the reality of the ISA any more, as now we have a 
much richer encoding for standard extensions.  The single-letter 
encoding is probably going to fall apart for some of these more 
complicated extensions, so we're not quite sure what we're going to do 
here because a bunch of ABIs were designed with single-letter 
extensibility in mind.

For now I think it's safest to have QEMU be careful here, so we don't 
end up with a proliferation of these mushy ABIs into userspace.  I 
wouldn't be opposed to adding a more explicit "get the ISA string I can 
use in my program" syscall (maybe a prctl?) to Linux, but it'd be best 
if we go hash that out on the mailing lists first.