On 10 May 2018 at 14:12, Alex Bennée <alex.ben...@linaro.org> wrote: > > Abdallah Bouassida <abdallah.bouass...@lauterbach.com> 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
