From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75731 invoked by alias); 7 Jun 2016 16:04:29 -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 75248 invoked by uid 89); 7 Jun 2016 16:04:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=emulator, protections, faces, internally X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Jun 2016 16:04:27 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 669F78553B; Tue, 7 Jun 2016 16:04:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u57G4O7Y023235; Tue, 7 Jun 2016 12:04:25 -0400 Subject: Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives To: Yao Qi References: <20160606075945.GA19395@host1.jankratochvil.net> <86eg89w2sr.fsf@gmail.com> <48622de4-dc45-c48f-7172-495b669f2334@redhat.com> <86a8ixvx5k.fsf@gmail.com> Cc: Jan Kratochvil , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <7fabd183-eb46-e916-77f2-f62d5c4e4ce7@redhat.com> Date: Tue, 07 Jun 2016 16:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <86a8ixvx5k.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00142.txt.bz2 On 06/07/2016 04:25 PM, Yao Qi wrote: > Pedro Alves writes: >> A gdbarch method poses problems for remote stubs that are actually emulators, >> 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. Isn't that what Jan's patch did? In any case, with the gdbarch method, if the target supports watching all kinds of unaligned addresses/ranges, and reports the correct address in "T05 watch" stop replies, it then faces the problem that gdb has hardcoded knowledge of watch region alignment restrictions, and then e.g., watchpoints on consecutive addresses are misinterpreted, even though there's no reason for that. E.g., say gdb believes the machine only supports watching 32-bit-aligned words. Then with: union { char buf[4]; uint32_t force_align; } global; (gdb) watch global.buf[1]; Hardware watchpoint 1 ... (gdb) watch global.buf[3]; Hardware watchpoint 2 ... ... if the program writes to global.buf[1], and the target reports a memory access to 'global.buf + 1', gdb will believe that watchpoint 2 _also_ triggered, when it did not. That's a false positive you can't help with with real machines, but there's no reason a simulator/emulator has to suffer from that. > >> 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. I think we need to consider all architectures, and the design going forward, not just Aarch64. For example, PPC has: static int ppc_linux_watchpoint_addr_within_range (struct target_ops *target, CORE_ADDR addr, CORE_ADDR start, int length) { int mask; if (have_ptrace_hwdebug_interface () && ppc_linux_get_hwcap () & PPC_FEATURE_BOOKE) return start <= addr && start + length >= addr; else if (ppc_linux_get_hwcap () & PPC_FEATURE_BOOKE) mask = 3; else mask = 7; So e.g., here, the alignment restrictions depend on both the processor model and kernel. (I'll guess that other embedded architectures that gdb supports probably have similar restrictions that gdb was never taught about.) > 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, How can gdb determine whether the restriction has been lifted? The way to do it is probably either by checking kernel version or having the ptrace code that "inserts" the watchpoint to first try watching the unaligned region exactly as gdb requested, and if that doesn't work, try a wider, aligned region. Only that target-side ptrace code is aware of these finer details and the correct restrictions in effect for the running system. If we put this in a gdbarch method, how can the gdbarch method maintain compatibility with older kernels and at the same time reflect that newer kernels no longer impose the restriction? It's actually not just simulators/emulators that can have different watchpoint restrictions from the machine architecture's debug hardware limitations. This is in good part a debug API issue as well -- a target may well support watchpoints implemented in a totally different way -- for example, I believe Solaris supports "unlimited" watchpoints and address ranges by implementing watchpoints not by using debug registers, but instead by changing memory page protections and trapping faults internally, all invisibly to userspace. All this is why I believe that hardcoding this knowledge in gdb, which is what a gdbarch method does, is not the best approach. Thanks, Pedro Alves