From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11162 invoked by alias); 25 Nov 2010 17:32:12 -0000 Received: (qmail 11150 invoked by uid 22791); 25 Nov 2010 17:32:10 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Nov 2010 17:32:04 +0000 Received: (qmail 18792 invoked from network); 25 Nov 2010 17:32:02 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Nov 2010 17:32:02 -0000 From: Pedro Alves To: Thiago Jung Bauermann Subject: Re: [patch 2/3] Implement support for PowerPC BookE ranged watchpoints Date: Thu, 25 Nov 2010 17:32:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: gdb-patches@sourceware.org, Jan Kratochvil , Joel Brobecker , Eli Zaretskii References: <1290549100.3164.47.camel@hactar> <201011232316.56539.pedro@codesourcery.com> <1290632755.3164.94.camel@hactar> In-Reply-To: <1290632755.3164.94.camel@hactar> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011251731.58135.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2010-11/txt/msg00430.txt.bz2 On Wednesday 24 November 2010 21:05:55, Thiago Jung Bauermann wrote: > On Tue, 2010-11-23 at 23:16 +0000, Pedro Alves wrote: > > On Tuesday 23 November 2010 21:51:40, Thiago Jung Bauermann wrote: > > > Ok? > > > > Apologies for jumping in so late, but, I don't think I understand > > why does the user need to know that a watchpoint is "ranged" > > or not. All (low-level) watchpoints are ranged, > > Good point. At the time these patches were made, GDB didn't behave that > way, but it was fixed one year ago already[1]. I guess I just kept the > old mentality... That patch helped in the array case (maybe it was even a regression that was fixed?), but even the structure case, gdb always behaved the "ranged" way, AFAIK. E.g., if you "(gdb) watch" an int, assuming 32-bit, gdb is supposed to be watching the range of 4 bytes starting from the int's address. And watching "int i;" is supposed to be the same as watching "struct {int i;} i"; > > > and what's > > relevant here is only the width of the range the hardware can watch, > > but that is already a parameter to the target_insert_watchpoint > > method. So I guess my question is, why can't the target backend > > manage whether to use a range or "normal" watchpoint when asked to > > inserted a watchpoint? Is it the watch resource accounting done > > by breakpoint.c (which is known to be something that should just > > go away)? > > Yes, the resource accounting is an issue. > But also, the target needs to > know that it's being asked to watch a region which is expected to have > accesses in the middle of it. This is because of the difference of how > hardware watchpoints work in server and embedded PowerPC processors. In > the former, a hardware watchpoint triggers when any byte within an 8 > byte window starting at the given address is accessed. In the latter, > only accesses at the given address trigger the watchpoint. Hmm.. Oh? Without knowing a think about BookE, that is not what I'd infer from: static int ppc_linux_region_ok_for_hw_watchpoint (CORE_ADDR addr, int len) { /* Handle sub-8-byte quantities. */ if (len <= 0) return 0; /* The new BookE ptrace interface tells if there are alignment restrictions for watchpoints in the processors. In that case, we use that information to determine the hardcoded watchable region for watchpoints. */ if (have_ptrace_booke_interface ()) { if (booke_debug_info.data_bp_alignment && (addr + len > (addr & ~(booke_debug_info.data_bp_alignment - 1)) + booke_debug_info.data_bp_alignment)) return 0; } /* addr+len must fall in the 8 byte watchable region for DABR-based processors (i.e., server processors). Without the new BookE ptrace interface, DAC-based processors (i.e., embedded processors) will use addresses aligned to 4-bytes due to the way the read/write flags are passed in the old ptrace interface. */ else if (((ppc_linux_get_hwcap () & PPC_FEATURE_BOOKE) && (addr + len) > (addr & ~3) + 4) || (addr + len) > (addr & ~7) + 8) return 0; return 1; } The use of "addr + len" in both BookE cases above seems to allow setting a BookE exact PPC_BREAKPOINT_MODE_EXACT watchpoint watching [0x..002, 0x..003] (say, eith an "int foo" global, watch ((char *)&foo)[2]), but, if this only traps on exact address matches, rather than on accesses within the watchable regision, why is there a "len" contemplated? Confusing. > So for an embedded powerpc processor, it's not enough to know that it > should watch a 4 byte region at a given address. If it represents an > integer and thus it can expect accesses only at that address then a > regular watchpoint is enough. But if it's an array of four chars, then > it needs two watchpoint registers to set up a hardware watchpoint... It all looks to me that the "ranged" notion is backwards. The default watchpoint that GDB expects to handle _is_ ranged. E.g., that's how it works on x86, and DABR based PPC. That's why this: +* GDB now supports ranged watchpoints, which stop the inferior when it + accesses any address within a specified memory range. Is just confusing, because this is not a new GDB feature. BTW, it's not only useful to watch the whole range of a structure or arrays. It's often useful to watch what random code is clobbering an int or pointer. The bad write may well be to the middle of the integer or pointer. I bet that users end up surprised if PPC doesn't catch that with gdb's "watch" command. > So that's way I created a target_insert_ranged_watchpoint. The other > option would be to add a flag to target_insert_watchpoint... It appears to me that if there should be a new kind of way to insert watchpoints, it should be to allow setting watchpoints that only work if the accesses are aligned, that is to support the behaviour you describe with PPC_BREAKPOINT_MODE_EXACT in embedded processors. -- Pedro Alves