Re: Hardware watchpoints on GNU/Linux AArch64

Andrew Pinski via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CA+=Sn1=DKM1fxm8MrOTgox6zdQE_RqBXtKdmQdLskHPhKdi4CQ@mail.gmail.com>
On Mon, Jan 2, 2023 at 9:39 AM Andrew Pinski <[email protected]> wrote:
>
> On Mon, Jan 2, 2023 at 9:28 AM Andrew Pinski <[email protected]> wrote:
> >
> > On Mon, Jan 2, 2023 at 8:49 AM Florian Weimer via Gdb
> > <[email protected]> wrote:
> > >
> > > Running
> > >
> > > gdb-12.1-10.fc38.aarch64
> > > kernel-6.2.0-0.rc1.20221230gitbff687b3dad6.15.fc38.aarch64
> > >
> > > I do not seem to be able to use hardware watchpoints.  GDB just logs
> > > warnings:
> > >
> > > warning: Unable to determine the number of hardware watchpoints available.
> > > warning: Unable to determine the number of hardware breakpoints available.
> >
> > This shows up when the ptrace either fails or ptrace returns an
> > unknown value for AARCH64_DEBUG_ARCH value.
> > In the boot log there should be a message saying how many HW
> > breakpoint and watchpoints there are and what version of the debug
> > arch is there.
> > The supported values for debug arch are:
> > #define AARCH64_DEBUG_ARCH_V8 0x6
> > #define AARCH64_DEBUG_ARCH_V8_1 0x7
> > #define AARCH64_DEBUG_ARCH_V8_2 0x8
> > #define AARCH64_DEBUG_ARCH_V8_4 0x9
> >
> > I don't know of any other values that can be reported, especially for
> > Neoverse-N1 (which should be 8_2). Neoverse-N2 is 8_4.
>
> The kernel fills in that field with ptrace via:
> u8 debug_monitors_arch(void)
> {
>         return cpuid_feature_extract_unsigned_field(read_sanitised_ftr_reg(SYS_ID_AA64DFR0_EL1),
>                                                 ID_AA64DFR0_EL1_DebugVer_SHIFT);
> }
>
> So either kvm/qemu is setting that EL1 (system) register incorrectly
> or the KVM Invocation didn't turn on HW breakpoints. Or KVM does not
> support HW breakpoints yet.

Looking KVM sources (arch/arm64/kvm/sys_regs.c) inside the kernel we see:
                /* Limit debug to ARMv8.0 */
                val &= ~ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_DebugVer);
                val |=
FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_DebugVer), 6);
Which was added by 94893fc9ad8cd for 5.12 unless this changed post Linux 6.0 .
So a value of 6 should be good to go.

Thanks,
Andrew Pinski


>
> Thanks,
> Andrew
>
>
> >
> > Thanks,
> > Andrew Pinski
> >
> > >
> > > I see AArch64-specific code in GDB, so this is a bit of a surprise to
> > > me.
> > >
> > > The machine uses virtualization:
> > >
> > > Architecture:           aarch64
> > >   CPU op-mode(s):       32-bit, 64-bit
> > >   Byte Order:           Little Endian
> > > CPU(s):                 3
> > >   On-line CPU(s) list:  0-2
> > > Vendor ID:              ARM
> > >   BIOS Vendor ID:       QEMU
> > >   Model name:           Neoverse-N1
> > >     BIOS Model name:    virt-rhel8.6.0  CPU @ 2.0GHz
> > >     BIOS CPU family:    1
> > >     Model:              1
> > >     Thread(s) per core: 1
> > >     Core(s) per socket: 1
> > >     Socket(s):          3
> > >     Stepping:           r3p1
> > >     BogoMIPS:           50.00
> > >     Flags:              fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp
> > >                          asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
> > >
> > > Is this actually expected to work?  Would we have more luck on a
> > > bare-metal system?
> > >
> > > Thanks,
> > > Florian
> > >
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.