[v1, 2/3] RISC-V: vector: export VLENB csr in __sc_riscv_v_state
Maciej W. Rozycki
macro at orcam.me.uk
Thu Aug 17 05:35:43 PDT 2023
On Wed, 16 Aug 2023, Andy Chiu wrote:
> diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h
> index e17c550986a6..283800130614 100644
> --- a/arch/riscv/include/uapi/asm/ptrace.h
> +++ b/arch/riscv/include/uapi/asm/ptrace.h
> @@ -97,6 +97,7 @@ struct __riscv_v_ext_state {
> unsigned long vl;
> unsigned long vtype;
> unsigned long vcsr;
> + unsigned long vlenb;
> void *datap;
I think we really ought to make a distinct structure holding the vector
CSR state only, and then have it included as a leading member of a pair of
other structures, one for the signal context with a trailing `datap' (or
`vregp' or `vreg') member and another one for the regset with a flexible
array member of the `char' type, e.g. (actual names TBD):
struct __riscv_v_csr_state {
unsigned long vstart;
unsigned long vl;
unsigned long vtype;
unsigned long vcsr;
unsigned long vlenb;
};
struct __riscv_v_signal_state {
struct __riscv_v_csr_state csr;
void *vregp;
};
struct __riscv_v_regset_state {
struct __riscv_v_csr_state csr;
char vreg[];
};
This will make the API cleaner and avoid both UB with making accesses
beyond the end of a structure and clutter with an unused entry in core
files and data exchanged via ptrace(2).
Since this is a part of the UAPI I suggest consulting with libc people,
possibly by posting an RFC to <libc-alpha at sourceware.org>.
Maciej
More information about the linux-riscv
mailing list