From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8507 invoked by alias); 3 Mar 2009 21:33:28 -0000 Received: (qmail 8499 invoked by uid 22791); 3 Mar 2009 21:33:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Mar 2009 21:33:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B01B02BAB23; Tue, 3 Mar 2009 16:33:20 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yDH6pgEeOnuB; Tue, 3 Mar 2009 16:33:20 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6AF9B2BAB1C; Tue, 3 Mar 2009 16:33:20 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 0B39FE7ACD; Tue, 3 Mar 2009 13:33:15 -0800 (PST) Date: Tue, 03 Mar 2009 21:33:00 -0000 From: Joel Brobecker To: Thiago Jung Bauermann Cc: gdb ml , Luis Machado , =?iso-8859-1?Q?S=E9rgio_Durigan_J=FAnior?= Subject: Re: support for BookE hardware debug features Message-ID: <20090303213314.GB4041@adacore.com> References: <1236026362.8949.96.camel@localhost.localdomain> <20090302205516.GF3632@adacore.com> <1236108731.30573.58.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1236108731.30573.58.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00029.txt.bz2 > I was thinking about something along those lines too. Possibly adding a > target hook which would receive a struct expression with the condition > and a watchpoint address, and return true if it can be > hardware-accelerated. That hook would also set up the hardware debug > registers accordingly. That should work, at least for now. The downside, as I was saying, is that each target will possibly have to duplicate the expression tree analysis. I more targets start popping up with this feature, perhaps we'll have to think of a more generic approach where we pass the result of the analysis to the hook rather than let the hook do the analysis. In the meantime, it's probably not worth worrying too much about genericity if only one target in the FSF tree supports it. (our VxWorks implementation has still a couple of key parts that need to be improved before we can think of contributing it) > Regarding what is a viable approach, our main concern is that we do it > in a way which will be accepted upstream. I personally don't see any problem with that, if it's just a well defined hook. > Thanks for sharing this code, by the way. Just a question to be on the > safe side: is there any copyright implication if we stare at it for too > long (half-joking)? No problem at all, I wrote the code, and it's not confidential. If it's any help to you, then by all means, use it in any way. -- Joel