Hi Alex, First of all, thanks for the review! >> +static int arm_gdb_get_sysreg(CPUARMState *env, uint8_t *buf, int reg) >> +{ >> + ARMCPU *cpu = arm_env_get_cpu(env); >> + const ARMCPRegInfo *ri; >> + uint32_t key; >> + >> + key = cpu->dyn_xml.cpregs_keys[reg]; >> + ri = get_arm_cp_reginfo(cpu->cp_regs, key); >> + if (ri) { >> + if (cpreg_field_is_64bit(ri)) { >> + return gdb_get_reg64(buf, (uint64_t)read_raw_cp_reg(env, ri)); >> + } else { >> + return gdb_get_reg32(buf, (uint32_t)read_raw_cp_reg(env, ri)); >> + } >> + } >> + return 0; > There is something odd going on here because if I run a simple little > features binary > (https://github.com/stsquad/testcases/blob/master/aarch64/features.c) I > get: > > ID_AA64ISAR0_EL1 : 0x0000000000011120 > ID_AA64ISAR1_EL1 : 0x0000000000000000 > ID_AA64MMFR0_EL1 : 0x00000000ff000000 > ID_AA64MMFR1_EL1 : 0x0000000000000000 > ID_AA64PFR0_EL1 : 0x0000000000000011 > ID_AA64PFR1_EL1 : 0x0000000000000000 > ID_AA64DFR0_EL1 : 0x0000000000000006 > ID_AA64DFR1_EL1 : 0x0000000000000000 > MIDR_EL1 : 0x00000000411fd070 > MPIDR_EL1 : 0x0000000080000000 > REVIDR_EL1 : 0x0000000000000000 > > However in the gdb output we see: > > ID_AA64ISAR0_EL1 0x11120 69920 > ID_AA64ISAR1_EL1 0x0 0 > ID_AA64MMFR0_EL1 0x1124 4388 <-? > ID_AA64MMFR1_EL1 0x0 0 > ID_PFR0 0x131 305 <-name and value? > ID_AA64PFR1_EL1 0x0 0 > ID_AA64DFR0_EL1 0x10305106 271601926 <-? > ID_AA64DFR1_EL1 0x0 0 > REVIDR_EL1 0x0 0 > > So why the discrepancies?
> ID_AA64MMFR0_EL1 0x1124 4388 <-? > ID_AA64DFR0_EL1 0x10305106 271601926 <-? I get the same value in x1 (= 0x1124) and x2 (= 0x10305106) when I execute the following instructions on the guest: MRS x1, ID_AA64MMFR0_EL1 MRS x2, ID_AA64DFR0_EL1 So, I think that there is no problem on how GDB is reading these registers! > ID_PFR0 0x131 305 <-name and value? This is not ID_AA64PFR0_EL1 - the ID_AA64PFR0_EL1 is not registered in our dynamic XML as it has "ARM_CP_NO_RAW" type. So should we add some modifications to handle this special case? Best regards, Abdallah