From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E1FA43858D32; Fri, 14 Apr 2023 10:55:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E1FA43858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681469729; bh=HhSvh5jD6+krsUHFiHP1BzNLhiw6L+9DBjBE0GnpL6U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HA/XSDIU7QPhniW9IgmlINs1DDpaoEsV08luS+Q3e6Ek3DVe7zZdFn58sqtPgQQpq ux5hmpXLl830pqkZcGvepTeassGfFA25aJ/QE2X9onl1wUcU88xlmZA+NRNkMxxVp2 aFFwOVr/ax7kd7cIUo+v4wpAO4DCTVeNQAfYRNm8= From: "ahajkova at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/30340] gdb.base/watchpoint-unaligned.exp produces TCL error Date: Fri, 14 Apr 2023 10:55:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ahajkova at redhat dot com X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: luis.machado at arm dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30340 --- Comment #9 from Alexandra H=C3=A1jkov=C3=A1 --- (In reply to Luis Machado from comment #8) > Thanks! >=20 > The ptrace requests for the debug registers seem to be going through just > fine: >=20 > ptrace(PTRACE_GETREGSET, 1832792, NT_ARM_HW_WATCH, {iov_base=3D0xffffc0ea= 3b88, > iov_len=3D264}) =3D 0 >=20 > ptrace(PTRACE_GETREGSET, 1832792, NT_ARM_HW_BREAK, {iov_base=3D0xffffc0ea= 3b88, > iov_len=3D264}) =3D 0 >=20 > I think this rules out permissions issues with ptrace, and we're back at > suspecting the architecture level comparisons. >=20 > Since you have ready access to the hardware, would you mind running a qui= ck > check on your side? >=20 > In gdb/nat/aarch64-linux-hw-point.c:compatible_debug_arch, could you plea= se > add a warning statement printing the debug_arch? Like we do for example in > aarch64_linux_get_debug_reg_capacity when printing the number of > watchpoints/breakpoints. >=20 > Then rebuild gdb, run the test (to create the test executable) and attempt > to run that same command line we used for strace. >=20 > Could you then paste the architecture level that is printed? >=20 > Also, could you please paste the output of "cat /proc/cpuinfo"? >=20 > Thanks! I'm getting 0 for the debug_arch. as for the cpuinfo: processor : 0 BogoMIPS : 50.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x3 CPU part : 0xd0c CPU revision : 1 processor : 1 BogoMIPS : 50.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x3 CPU part : 0xd0c CPU revision : 1 processor : 2 BogoMIPS : 50.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x3 CPU part : 0xd0c CPU revision : 1 processor : 3 BogoMIPS : 50.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x3 CPU part : 0xd0c CPU revision : 1 Should I update my patch to check for any warnings/errors or do you just wa= nt to take care of this issue yourself? --=20 You are receiving this mail because: You are on the CC list for the bug.=