On Tue, Nov 24, 2015 at 09:08:29PM +0000, Peter Maydell wrote:
> On 24 November 2015 at 20:52, Andrew Jones <drjo...@redhat.com> wrote:
> >
> > I've pulled a v2 together that I'll be testing and posting soon. Here's
> > what I decided to do
> >
> > 1) Throw the fp registers in. Why not?
> > 2) No linux-headers update, as we'd also need
> > include/uapi/linux/elfcore.h and arch/arm/include/asm/user.h.
> > However I've added comments stating where the structs come from.
> > 3) Base the vmcore type on the guest kernel, i.e. use arm_el_is_aa64()
> > and (env->cp15.sctlr_el[1] & SCTLR_EE). However,
> > aarch64_write_elf64_note() will shoehorn 32-bit state into 64-bit
> > elf notes when the current state is 32-bit. Those analyzing the
> > dumps will need to look at the captured pstate to determine the
> > endianness of the registers.
>
> Not sure what you have in mind by "endianness of the registers" --
> typically registers aren't thought of as having endianness.
If a processor that was temporarily switched into the opposite endian
had just read a memory address into a register before generating the
core, then the data in that register will be in the format of that
temporary endianness. The person doing the dump analysis will need to
keep in mind that even though they should interpret a crash-tool read of
that same address in the endianness of the core type, the register will
have it swapped. Or maybe I'm wrong about how that should work?
>
> Also, if we're currently executing a 32-bit guest when we take
> the core dump, you probably need to call aarch64_sync_32_to_64()
> somewhere.
I think we're covered here. We have
dump_init
cpu_synchronize_all_states
...
kvm_arch_get_registers
if (!is_a64(env)) {
aarch64_sync_64_to_32(env);
}
Thanks,
drew
