[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] linux-user/riscv: fix up struct target_ucontext definition
From: |
Alistair Francis |
Subject: |
Re: [PATCH] linux-user/riscv: fix up struct target_ucontext definition |
Date: |
Wed, 22 Apr 2020 11:05:05 -0700 |
On Tue, Apr 21, 2020 at 9:10 PM Richard Henderson
<address@hidden> wrote:
>
> On 4/21/20 7:34 PM, LIU Zhiwei wrote:
> > Ping.
> >
> > When I port RISU, I find this bug. I can't get the correct registers from
> > the
> > struct ucontext_t parameter in the signal handler.
>
> The RISC-V Linux ABI will need to be extended to handle RVV state.
>
> There is room in your sigcontext structure:
>
> > struct __riscv_q_ext_state {
> > __u64 f[64] __attribute__((aligned(16)));
> > __u32 fcsr;
> > /*
> > * Reserved for expansion of sigcontext structure. Currently zeroed
> > * upon signal, and must be zero upon sigreturn.
> > */
> > __u32 reserved[3];
> > };
>
> in uc->uc_mcontext.sc_fpregs.q.
>
> That reserved field is going to have to be used in some way.
Just to clarify, this patch is still correct right?
It looks good to me.
Alistair
>
> My suggestion is to use some sort of extendable record list, akin to AArch64:
>
> struct _aarch64_ctx {
> __u32 magic;
> __u32 size;
> };
>
> One of the 3 zeros could be the total size of the extensions, so that it's
> easy
> to validate the size or memcpy the lot without parsing each individual record.
> The other two zeros could be the first header of the next record. Which in
> this case also allows the payload of that first record to be aligned mod 16,
> which could come in handy.
>
> Talk to the risc-v kernel engineers and come up with a plan that includes room
> for the next architecture extension as well. They may have already done so,
> but I'm not monitoring the correct mailing list to know.
>
>
> r~
>