Re: [Qemu-devel] [PATCH v6 0/3] target/arm: Add a dynamic XML-description of the cp-registers to GDB

[Peter Maydell]

On 10 May 2018 at 14:12, Alex Bennée <address@hidden> wrote:
>
> Abdallah Bouassida <address@hidden> writes:
>
>> The previous version:
>> http://patchwork.ozlabs.org/project/qemu-devel/list/?series=33714
>>
>> Abdallah Bouassida (3):
>>   target/arm: Add "ARM_CP_NO_GDB" as a new bit field for ARMCPRegInfo
>>     type
>>   target/arm: Add "_S" suffix to the secure version of a sysreg
>>   target/arm: Add the XML dynamic generation
>>
>
> So I got a fixed up gdb and I was testing the reading of the virtual
> counter:
>
> => 0xffffff800854a118 <arch_counter_get_cntvct+16>:     mrs     x0, cntvct_el0
>    0xffffff800854a11c <arch_counter_get_cntvct+20>:     b       
> 0xffffff800854a148 <arch_counter_get_cntvct+64>
>    0xffffff800854a120 <arch_counter_get_cntvct+24>:     adrp    x0, 
> 0xffffff800896a000 <scsi_format_log+3568>
>    0xffffff800854a124 <arch_counter_get_cntvct+28>:     add     x0, x0, #0x5a0
>    0xffffff800854a128 <erratum_set_next_event_tval_virt+4294964112>:    mrs   
>   x1, tpidr_el1
>
> p/x $x0
>  $6 = 0xffffff800854a108
> p/x $cntvct_el0
>  $7 = 0x0
> stepi
> 0xffffff800854a11c      160             return 
> arch_timer_reg_read_stable(cntvct_el0);
> => 0xffffff800854a11c <arch_counter_get_cntvct+20>:     b       
> 0xffffff800854a148 <arch_counter_get_cntvct+64>
>    0xffffff800854a120 <arch_counter_get_cntvct+24>:     adrp    x0, 
> 0xffffff800896a000 <scsi_format_log+3568>
>    0xffffff800854a124 <arch_counter_get_cntvct+28>:     add     x0, x0, #0x5a0
> p/x $x0
>   $8 = 0x7a5b32b
> p/x $cntvct_el0
>   $9 = 0x0
>
> So I'm wondering why there is a disparity here?

CNTVCT_EL0 isn't in the set of registers we expose to gdb (it's
marked up as ARM_CP_NO_RAW), so I'm not sure why gdb is
giving you any value at all. Does it do that for any
random $no_such_thing strings ? Is CNTVCT_EL0 listed
if you ask gdb to display all registers?

thanks
-- PMM