From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49473 invoked by alias); 7 Jun 2016 15:25:35 -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 48967 invoked by uid 89); 7 Jun 2016 15:25:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.220.67, H*RU:209.85.220.67, 8bytealigned, 8-byte-aligned X-HELO: mail-pa0-f67.google.com Received: from mail-pa0-f67.google.com (HELO mail-pa0-f67.google.com) (209.85.220.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 07 Jun 2016 15:25:33 +0000 Received: by mail-pa0-f67.google.com with SMTP id gp3so14419721pac.2 for ; Tue, 07 Jun 2016 08:25:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=TucdN5d8LTal4FdulSIMYBdwgLZdAfGfJNcxgNEoRyo=; b=l+BpXexXG7Lmnzz1cnAdrGSqcgdev178iXWqtG6JUO3AbTZdaeq/BsbrR0nAaU5dNq uzyrVAZvV3gYem/oxbu4iDsNXwWm3dadEA5DGN44oUHEArm9fAstdGX8pzNKUaUOvE5a o2eOW1yzqJ0EFt0M9aDeo5utBj9jR1AyAhxHcoiRBLZj7WS27WBXjUWMDHouck+RxjAJ Epoxe3wOTilTPcyQjGjjEbbkEKPT/OSrQBzaq3xaZatjHaTVFiC5w3XlcTRVgfkgeRug YB9Okh0TBrTqORy7Usdez0DxAnBRqTk/LAd5B5nKhT0CATLg1Ws6hg04shzAVYm6TuNa EmlQ== X-Gm-Message-State: ALyK8tKRv0SZFXgiTljIIls+NSmYvv/Ug/c52qB83e1EZem8FMbiYMJC0UFZQ509KfCN2g== X-Received: by 10.66.230.162 with SMTP id sz2mr18521164pac.138.1465313131538; Tue, 07 Jun 2016 08:25:31 -0700 (PDT) Received: from E107787-LIN (gcc113.osuosl.org. [140.211.9.71]) by smtp.gmail.com with ESMTPSA id lq8sm33915622pab.40.2016.06.07.08.25.29 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 07 Jun 2016 08:25:30 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives References: <20160606075945.GA19395@host1.jankratochvil.net> <86eg89w2sr.fsf@gmail.com> <48622de4-dc45-c48f-7172-495b669f2334@redhat.com> Date: Tue, 07 Jun 2016 15:25:00 -0000 In-Reply-To: <48622de4-dc45-c48f-7172-495b669f2334@redhat.com> (Pedro Alves's message of "Tue, 7 Jun 2016 14:41:02 +0100") Message-ID: <86a8ixvx5k.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00137.txt.bz2 Pedro Alves writes: > How do you plan on handling remote targets though? Done that way, it=20 > sounds to me like the alignment restrictions should either be a gdbarch > property, or you need some RSP extension, e.g., extend the "watch" stop > reply to indicate an stop data address range instead of a sole address, > or make the stub report back the alignment restriction when GDB tells it > to insert the watchpoint in the first place, instead of just saying > "OK". > I want to use a gdbarch method to decide whether a watchpoint is triggered in remote target, like this, [note that all the code below is not compiled at all] static enum watchpoint_triggered remote_watchpoint_triggered (struct target_ops *target, struct watchpoint *= w) { struct thread_info *thread =3D inferior_thread (); if (thread->priv !=3D NULL && thread->priv->stop_reason =3D=3D TARGET_STOPPED_BY_WATCHPOINT) { return gdbarch_watchpoint_triggered (w->base.gdbarch, w, thread->priv->watch_data_address); } return watchpoint_triggered_unknown; } The default implementation of gdbarch_watchpoint_triggered returns watchpoint_triggered_yes if address is in the range of loc->address,+loc->length. Otherwise return watchpoint_triggered_no. Then, we can rewrite breakpoint.c:watchpoints_triggered like this, int watchpoints_triggered (void) { int ret =3D 0; ALL_BREAKPOINTS (b) if (is_hardware_watchpoint (b)) { struct watchpoint *w =3D (struct watchpoint *) b; w->watchpoint_triggered =3D target_watchpoint_triggered (w); if (w->watchpoint_triggered !=3D watch_triggered_no) ret =3D 1; } return ret; } > A gdbarch method poses problems for remote stubs that are actually emulat= ors, > and thus can support hardware watchpoints without these restrictions. Then, the address reported by the target should fall in the range of loc->address,+loc->length. > I think it's actually problematic for real machines, as the restrictions > will often depend on process revisions/models. So a gdbarch approach > would be undesirable, IMO. On the real machine, nowadays, the restriction is that address must be 8-byte-aligned on linux. The restriction can only be relaxed and may be removed finally in the future, IOW, the restriction won't become 16-byte aligned, so we can write the gdbarch method for aarch64-linux like this, static enum watchpoint_triggered aarch64_linux_watchpoint_triggered (struct gdbarch *gdbarch, struct watchpoint *w, CORE_ADDR addr) { struct bp_location *loc; for (loc =3D w->base.loc; loc; loc =3D loc->next) { if (addr >=3D loc->address && addr < loc->address + loc->length) { /* If the address reported by the target falls in the memory range that watchpoint W is monitoring, the watchpoint is definitely hit. */ return watchpoint_triggered_yes; } else if (addr >=3D align_down (loc->address, 8) && addr < loc->addres= s) { /* The debugging stub, like GDBserver, may adjust the address to meet kernel's alignment requirements (8-aligned for example), we are not sure watchpoint W is hit or not. */ return watchpoint_triggered_unknown; } } return watchpoint_triggered_no; } --=20 Yao (=E9=BD=90=E5=B0=A7)