From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83018 invoked by alias); 13 Oct 2015 16:58:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 83003 invoked by uid 89); 13 Oct 2015 16:58:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f175.google.com Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 13 Oct 2015 16:58:46 +0000 Received: by lbwr8 with SMTP id r8so27694008lbw.2 for ; Tue, 13 Oct 2015 09:58:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.25.150.4 with SMTP id y4mr7046650lfd.57.1444755522931; Tue, 13 Oct 2015 09:58:42 -0700 (PDT) Received: by 10.25.160.73 with HTTP; Tue, 13 Oct 2015 09:58:42 -0700 (PDT) In-Reply-To: <861tcy6b84.fsf@gmail.com> References: <1444731060-16237-1-git-send-email-yao.qi@linaro.org> <561CE5D2.8030505@redhat.com> <861tcy6b84.fsf@gmail.com> Date: Tue, 13 Oct 2015 16:58:00 -0000 Message-ID: Subject: Re: [PATCH] aarch64 multi-arch part 6: HW breakpoint on unaligned address From: Andrew Pinski To: Yao Qi Cc: Pedro Alves , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00184.txt.bz2 On Tue, Oct 13, 2015 at 8:26 AM, Yao Qi wrote: > Pedro Alves writes: > >>> + { >>> + if (len =3D=3D 3) >>> + len =3D 2; >> >> I think this warrants a comment. E.g., someone reading >> arm-linux-low.c:arm_linux_hw_point_initialize quite easily grasps >> what 3 means. >> > > How about the comment like this? > > if (len =3D=3D 3) > { > /* LEN is 3 means the breakpoint is set on a 32-bit thumb > instruction. Set it to 2 to correctly encode length bit > mask in hardware/watchpoint control register. */ > len =3D 2; > } > >>> diff --git a/gdb/nat/aarch64-linux-hw-point.c b/gdb/nat/aarch64-linux-h= w-point.c >>> index bca6ec1..d15e518 100644 >>> --- a/gdb/nat/aarch64-linux-hw-point.c >>> +++ b/gdb/nat/aarch64-linux-hw-point.c >>> @@ -112,8 +112,17 @@ aarch64_point_encode_ctrl_reg (enum target_hw_bp_t= ype type, int len) >>> static int >>> aarch64_point_is_aligned (int is_watchpoint, CORE_ADDR addr, int len) >>> { >>> - unsigned int alignment =3D is_watchpoint ? AARCH64_HWP_ALIGNMENT >>> - : AARCH64_HBP_ALIGNMENT; >>> + unsigned int alignment =3D 0; >>> + >>> + if (is_watchpoint) >>> + alignment =3D AARCH64_HWP_ALIGNMENT; >>> + else >>> + { >>> + /* Set alignment to 2 only if the current process is 32-bit, >>> + since thumb instruction can be 2-byte aligned. Otherwise, set >>> + alignment to AARCH64_HBP_ALIGNMENT. */ >>> + alignment =3D 2; >> >> Is some other code doing what the comment says? I'm not seeing >> any obvious 32-bit check. > > No, I don't do the 32-bit check here. Ideally, we should set alignment > to 2 only when the process is 32-bit, and still use 4 as alignment > otherwise. However, I don't find an easy way to do the 32-bit check > here, because this code is used by both GDB and GDBserver. We can do > the 32-bit check in GDB and GDBserver respectively, and pass the result > to nat/aarch64-linux-hw-point.c, but I don't like putting information down > multiple levels like this. Also it is not just about 32bit vs 64bit either. It is about aarch32 vs aarch64. I think we should push that information down as far as we can. Thanks, Andrew > > -- > Yao (=E9=BD=90=E5=B0=A7)