gdbstub.c | 10 +++++++ include/qom/cpu.h | 5 +++- target/arm/cpu.c | 1 + target/arm/cpu.h | 29 +++++++++++++++++++- target/arm/gdbstub.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++ target/arm/helper.c | 57 ++++++++++++++++++++++++++++++--------- 6 files changed, 164 insertions(+), 14 deletions(-)
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
gdbstub.c | 10 +++++++
include/qom/cpu.h | 5 +++-
target/arm/cpu.c | 1 +
target/arm/cpu.h | 29 +++++++++++++++++++-
target/arm/gdbstub.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++
target/arm/helper.c | 57 ++++++++++++++++++++++++++++++---------
6 files changed, 164 insertions(+), 14 deletions(-)
--
2.7.4
Abdallah Bouassida <abdallah.bouassida@lauterbach.com> writes: > The previous version: > http://patchwork.ozlabs.org/project/qemu-devel/list/?series=33714 I was trying to do some testing but I was finding it very hard to do at gdb kept throwing up errors like: (gdb) x/10i $pc => 0xffffff8008097760 <check_and_switch_context>: Cannot access memory at address 0xffffff8008097760 Detaching from program: /home/alex/lsrc/qemu/kernel-v8-plain.build/vmlinux, Remote target Ending remote debugging. However this seems to be the same on master as well so I wonder there is a regression somewhere. What was the last QEMU master commit you've tested these patches on? I'll do some more digging tomorrow. -- Alex Bennée
> Abdallah Bouassida <abdallah.bouassida@lauterbach.com> writes: > >> The previous version: >> http://patchwork.ozlabs.org/project/qemu-devel/list/?series=33714 > I was trying to do some testing but I was finding it very hard to do at > gdb kept throwing up errors like: > > (gdb) x/10i $pc > => 0xffffff8008097760 <check_and_switch_context>: Cannot access memory at address 0xffffff8008097760 > Detaching from program: /home/alex/lsrc/qemu/kernel-v8-plain.build/vmlinux, Remote target > Ending remote debugging. > > However this seems to be the same on master as well so I wonder there is > a regression somewhere. > > What was the last QEMU master commit you've tested these patches on? > I'll do some more digging tomorrow. It was: commit 0e87fdc966d05f4e5ad868034fcd8ee2a08ca62d Author: Peter Maydell <peter.maydell@linaro.org> Date: Wed Apr 4 20:37:20 2018 +0100 Update version for v2.12.0-rc2 release Best regards, Abdallah
On 3 May 2018 at 20:48, Alex Bennée <alex.bennee@linaro.org> wrote: > > Abdallah Bouassida <abdallah.bouassida@lauterbach.com> writes: > >> The previous version: >> http://patchwork.ozlabs.org/project/qemu-devel/list/?series=33714 > > I was trying to do some testing but I was finding it very hard to do at > gdb kept throwing up errors like: > > (gdb) x/10i $pc > => 0xffffff8008097760 <check_and_switch_context>: Cannot access memory at address 0xffffff8008097760 > Detaching from program: /home/alex/lsrc/qemu/kernel-v8-plain.build/vmlinux, Remote target > Ending remote debugging. > > However this seems to be the same on master as well so I wonder there is > a regression somewhere. What gdb version are you using? If it's a new one you may be running into https://sourceware.org/bugzilla/show_bug.cgi?id=23127 (a regression in gdb). thanks -- PMM
Abdallah Bouassida <abdallah.bouassida@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? -- Alex Bennée
On 10 May 2018 at 14:12, Alex Bennée <alex.bennee@linaro.org> wrote: > > Abdallah Bouassida <abdallah.bouassida@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
Peter Maydell <peter.maydell@linaro.org> writes:
> On 10 May 2018 at 14:12, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Abdallah Bouassida <abdallah.bouassida@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 ?
*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 <alex.bennee@linaro.org>
--
Alex Bennée
On 16 May 2018 at 10:03, Alex Bennée <alex.bennee@linaro.org> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> 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....
My gdb ("GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1") gives
(gdb) p/x $cntvct_el0
$3 = Value can't be converted to integer.
or if you don't ask for the hex conversion:
(gdb) print $cntvct_el0
$2 = void
so this is either something fixed in a newer gdb than you
have, or alternately it's a regression if you're using a
newer gdb, which you should probably report upstream...
> So finally:
>
> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Thanks for the testing.
Abdallah: I've added this series to my target-arm.next queue,
so it should reach QEMU master some time next week. Thanks for
your efforts in working through QEMU's review process, and
sorry this took us so long to deal with.
-- PMM
>> So finally: >> >> Tested-by: Alex Bennée <alex.bennee@linaro.org> > Thanks for the testing. > > Abdallah: I've added this series to my target-arm.next queue, > so it should reach QEMU master some time next week. Thanks for > your efforts in working through QEMU's review process, and > sorry this took us so long to deal with. > > -- PMM Happy to collaborate with you guys! Thank you both for your reviews and your advises :) Best regards, Abdallah
ping Le 4/19/2018 à 4:56 PM, Abdallah Bouassida a écrit : > 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 > > gdbstub.c | 10 +++++++ > include/qom/cpu.h | 5 +++- > target/arm/cpu.c | 1 + > target/arm/cpu.h | 29 +++++++++++++++++++- > target/arm/gdbstub.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > target/arm/helper.c | 57 ++++++++++++++++++++++++++++++--------- > 6 files changed, 164 insertions(+), 14 deletions(-) >
© 2016 - 2024 Red Hat, Inc.