From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20309 invoked by alias); 1 Oct 2002 06:00:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20291 invoked from network); 1 Oct 2002 06:00:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Oct 2002 06:00:04 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g915fOi03372 for ; Tue, 1 Oct 2002 01:41:24 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g91602l28387 for ; Tue, 1 Oct 2002 02:00:02 -0400 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.251]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g915xxw10205 for ; Mon, 30 Sep 2002 22:59:59 -0700 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 614DF3DD5; Tue, 1 Oct 2002 01:59:43 -0400 (EDT) Message-ID: <3D9939CF.8050205@redhat.com> Date: Mon, 30 Sep 2002 23:00:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa:breakpoint] Correctly count watchpoints References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00800.txt.bz2 > On Mon, 30 Sep 2002, Andrew Cagney wrote: > > >> On the i386, one watch resource is two registers. > > > Why two? Some expressions might need 3 registers. If you use this > worst-case scenario, GDB will think it cannot watch more than a single > expression, and that some data types, such as double's, and complex > aggregates, such as struct's, cannot be watched at all. It's hardly a > Good Thing to refuse to set watchpoints based on inaccurate decisions > like this. You mentioned two :-) Under the current arangement, an architecture has two choices: - have target_can_use_hardware_watchpoints() always return true (most targets appear to do this) and then error while trying to insert the watchpoints. This is what the i386 currently does. - have target_can_use...() make use of the counts and return an indication based on that >> > But this is very hard or even impossible to do in practice. For >> > example, on a i386, if there are two watchpoint that watch the same >> > 4-byte aligned int variable, you need only one debug register to watch >> > them both, so counting each one as taking one resource is incorrect. > >> >> That is a bug. A further change would be to accumulate all the regions >> and eliminate any overlap from the count. > > > This requires a significant change in the high-level code of GDB: it > needs to pass all the information about all the ``active'' watchpoints to > the function that tells how many watchpoint resources are required for > the next watchpoint. I'm not so sure. I think this can be handled by: - keeping a list of the addr:len pairs needed by each watchpoint (and their ``cost'' (hmm, that's the correct word)). - iterating over all watchpoints, all addr:len pairs eliminating overlap and this is local to breakpoint.c. >> For an architecture to try and optimally allocate watchpoint resources, >> I don't think (cf opencore code) a list of ADDR:LEN pairs is sufficient. >> Instead it should be provided with all the watchpoint expressions. > > > So that means an architecture should know about GDB's expression-parsing > code. In effect, we are going to have the arch-specific code be tightly > coupled with arch-independent code in breakpoint.c and friends. The expression tree, yes. More scary again, it's on par with a compiler where the code needs to assign instructions and registers to expression elements. As I mentioned elsewhere I've seen it come as a feature request twice now. >> For instance, the hw_resources_used_count() function in my other patch >> could be made part of the architecture vector so that architectures, >> such as the i386, could override the default model using some other type >> of allocation scheme. > > > As I write above, overriding the default model is not enough, since the > application-level code doesn't feed the architecture with enough info. Yes. The function hw_resources_used_count() (nee hw_breakpoint_used_count()) is the real core to determining the number of watchpoints that are needed. It has complete information. I was thinking of allowing architectures to plug in a per-architecture equivalent. Andrew