qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v5 3/3] target/arm: Add the XML dynamic generation


From: Abdallah Bouassida
Subject: Re: [Qemu-arm] [PATCH v5 3/3] target/arm: Add the XML dynamic generation
Date: Fri, 6 Apr 2018 18:28:05 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]