Re: [Qemu-arm] [PATCH v2 6/6] target-arm: dump-guest-memory: add fpregset notes

[Peter Maydell]

On 25 November 2015 at 00:37, Andrew Jones <address@hidden> wrote:
> Also refactors note init code to avoid code duplication.

Can you squash those parts down into the preceding patch?

>
> Signed-off-by: Andrew Jones <address@hidden>
> ---
>  target-arm/arch_dump.c | 161 
> ++++++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 139 insertions(+), 22 deletions(-)
>
> diff --git a/target-arm/arch_dump.c b/target-arm/arch_dump.c
> index 5debe549d721d..8d74788411d79 100644
> --- a/target-arm/arch_dump.c
> +++ b/target-arm/arch_dump.c
> @@ -35,6 +35,16 @@ struct aarch64_user_regs {
>
>  QEMU_BUILD_BUG_ON(sizeof(struct aarch64_user_regs) != 272);
>
> +/* struct user_fpsimd_state from arch/arm64/include/uapi/asm/ptrace.h */

The kernel struct uses __uint128_t, not an array of uint64_t; that's
worth commenting because it clarifies what the expected format is.

> +struct aarch64_user_vfp_state {
> +    uint64_t vregs[64];
> +    uint32_t fpsr;
> +    uint32_t fpcr;
> +    char pad[8];
> +} QEMU_PACKED;
> +
> +QEMU_BUILD_BUG_ON(sizeof(struct aarch64_user_vfp_state) != 528);
> +
>  /* struct elf_prstatus from include/uapi/linux/elfcore.h */
>  struct aarch64_elf_prstatus {
>      char pad1[32]; /* 32 == offsetof(struct elf_prstatus, pr_pid) */
> @@ -51,10 +61,77 @@ QEMU_BUILD_BUG_ON(sizeof(struct aarch64_elf_prstatus) != 
> 392);
>  struct aarch64_note {
>      Elf64_Nhdr hdr;
>      char name[QEMU_ALIGN_UP(NOTE_NAMESZ, 4)];
> -    struct aarch64_elf_prstatus prstatus;
> +    union {
> +        struct aarch64_elf_prstatus prstatus;
> +        struct aarch64_user_vfp_state vfp;
> +    };
>  } QEMU_PACKED;
>
> -QEMU_BUILD_BUG_ON(sizeof(struct aarch64_note) != 412);
> +#define AARCH64_NOTE_HEADER_SIZE offsetof(struct aarch64_note, prstatus)
> +#define AARCH64_PRSTATUS_NOTE_SIZE \
> +            (AARCH64_NOTE_HEADER_SIZE + sizeof(struct aarch64_elf_prstatus))
> +#define AARCH64_FPREGSET_NOTE_SIZE \
> +            (AARCH64_NOTE_HEADER_SIZE + sizeof(struct 
> aarch64_user_vfp_state))
> +
> +static void aarch64_note_init(struct aarch64_note *note, DumpState *s,
> +                              Elf64_Word type, Elf64_Word descsz)
> +{
> +    memset(note, 0, sizeof(*note));
> +
> +    note->hdr.n_namesz = cpu_to_dump32(s, NOTE_NAMESZ);
> +    note->hdr.n_descsz = cpu_to_dump32(s, descsz);
> +    note->hdr.n_type = cpu_to_dump32(s, type);
> +
> +    memcpy(note->name, NOTE_NAME, NOTE_NAMESZ);
> +}
> +
> +static void arm_write_vregs(uint64_t *vregs, int num_regs,
> +                            CPUARMState *env, DumpState *s)
> +{
> +    int i;
> +
> +    for (i = 0; i < num_regs; ++i) {
> +        vregs[i] = cpu_to_dump64(s, env->vfp.regs[i]);
> +    }
> +
> +    if (s->dump_info.d_endian == ELFDATA2MSB) {
> +        /* We must always swap vfp.regs's 2n and 2n+1 entries when
> +         * generating BE notes, because even big endian hosts use
> +         * 2n+1 for the high half.
> +         */
> +        for (i = 0; i < num_regs/2; ++i) {
> +            uint64_t tmp = vregs[2*i];
> +            vregs[2*i] = vregs[2*i+1];
> +            vregs[2*i+1] = tmp;
> +        }

This swapping is correct for AArch64, where the core dump format
is an array of 128 bit Qn register values (which in QEMU
are stored in vfp.regs[2n+1]:vfp.regs[2n] as a pair of 64
bit values). However it's wrong for AArch32, where the core
dump format is an array of 64-bit Dn register values, which
in QEMU are just in vfp.regs[n].

(See the comment in target-arm/cpu.h about VFP/Neon register
state and different views of the register bank.)

> +static int
> +arm_write_elf32_fpregset(WriteCoreDumpFunction f, CPUARMState *env,
> +                         int id, DumpState *s)
> +{
> +    struct arm_note note;
> +    int ret;
> +
> +    arm_note_init(&note, s, NT_FPREGSET, sizeof(note.vfp));
> +
> +    arm_write_vregs(note.vfp.vregs, 32, env, s);
> +
> +    note.vfp.fpscr = cpu_to_dump32(s, vfp_get_fpscr(env));

Do consumers care if we write out a dump with FP register
state for a CPU which doesn't implement FP? (For AArch64
FP is always present, but for AArch32 it may not be.)

thanks
-- PMM