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

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> 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 ?

*sigh* yes....

> Is CNTVCT_EL0 listed
> if you ask gdb to display all registers?

I must have gotten confused parsing:

  CNTVOFF_EL2    0x0                 0
  CNTHP_CTL_EL2  0x0                 0
  CNTHP_CVAL_EL2 0x0                 0
  CNTHCTL_EL2    0x3                 3
  CNTV_CTL_EL0   0x0                 0
  CNTP_CVAL_EL0  0x13e39b327         5338936103
  CNTV_CVAL_EL0  0x0                 0
  CNTPS_CTL_EL1  0x0                 0
  CNTPS_CVAL_EL1 0x0                 0
  CNTP_CTL_EL0   0x1                 1

And of course case matters:

  (gdb) p/x $CNTP_CVAL_EL0
  $2 = 0x13e39b327
  (gdb) p/x $cntp_cval_el0
  $3 = 0x0

And gdb completion is broken so:

  p/x $CN<tab>
  completes to:
  p/x $CNTKCTL_EL1

So finally I tried another set of registers while tracing the early
bootcode:

  (gdb) p/x $SP_EL0
  $3 = 0x0
  (gdb) x/10i $pc
  => 0xffffff8008900290 <__primary_switched+16>:  msr     sp_el0, x5
     0xffffff8008900294 <__primary_switched+20>:  adrp    x8, 
0xffffff8008082000 <vectors>
     0xffffff8008900298 <__primary_switched+24>:  add     x8, x8, #0x0
     0xffffff800890029c <__primary_switched+28>:  msr     vbar_el1, x8
     0xffffff80089002a0 <__primary_switched+32>:  isb
     0xffffff80089002a4 <__primary_switched+36>:  stp     xzr, x30, [sp, #-16]!
     0xffffff80089002a8 <__primary_switched+40>:  mov     x29, sp
     0xffffff80089002ac <__primary_switched+44>:  adrp    x5, 
0xffffff800894f000 <tmp_cmdline.52085+2008>
     0xffffff80089002b0 <__primary_switched+48>:  str     x21, [x5, #280]
     0xffffff80089002b4 <__primary_switched+52>:  adrp    x4, 
0xffffff80086b6000 <kimage_vaddr>
  (gdb) p/x $x5
  $4 = 0xffffff8008980780
  (gdb) i
  413             adr_l   x8, vectors                     // load VBAR_EL1 with 
virtual
  => 0xffffff8008900294 <__primary_switched+20>:  adrp    x8, 
0xffffff8008082000 <vectors>
     0xffffff8008900298 <__primary_switched+24>:  add     x8, x8, #0x0
     0xffffff800890029c <__primary_switched+28>:  msr     vbar_el1, x8
  (gdb) p/x $SP_EL0
  $5 = 0xffffff8008980780
  (gdb) p/x $VBAR
  $6 = 0x0
  (gdb) i
  0xffffff8008900298      413             adr_l   x8, vectors                   
  // load VBAR_EL1 with virtual
  => 0xffffff8008900298 <__primary_switched+24>:  add     x8, x8, #0x0
     0xffffff800890029c <__primary_switched+28>:  msr     vbar_el1, x8
     0xffffff80089002a0 <__primary_switched+32>:  isb
  (gdb) i
  414             msr     vbar_el1, x8                    // vector table 
address
  => 0xffffff800890029c <__primary_switched+28>:  msr     vbar_el1, x8
     0xffffff80089002a0 <__primary_switched+32>:  isb
     0xffffff80089002a4 <__primary_switched+36>:  stp     xzr, x30, [sp, #-16]!
  (gdb) p/x $x8
  $7 = 0xffffff8008082000
  (gdb) p/x $VBAR
  $8 = 0x0
  (gdb) i
  415             isb
  => 0xffffff80089002a0 <__primary_switched+32>:  isb
     0xffffff80089002a4 <__primary_switched+36>:  stp     xzr, x30, [sp, #-16]!
     0xffffff80089002a8 <__primary_switched+40>:  mov     x29, sp
  (gdb) p/x $VBAR
  $9 = 0xffffff8008082000
  (gdb)

So finally:

Tested-by: Alex Bennée <address@hidden>

--
Alex Bennée