From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12893 invoked by alias); 4 Dec 2009 16:38:32 -0000 Received: (qmail 12883 invoked by uid 22791); 4 Dec 2009 16:38:31 -0000 X-SWARE-Spam-Status: No, hits=-2.5 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; Fri, 04 Dec 2009 16:38:27 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5111C2BAC45; Fri, 4 Dec 2009 11:38:25 -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 cuKe9i0-SmY7; Fri, 4 Dec 2009 11:38:25 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1D5AA2BAC3C; Fri, 4 Dec 2009 11:38:24 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 16CADF588A; Fri, 4 Dec 2009 08:38:19 -0800 (PST) Date: Fri, 04 Dec 2009 16:38:00 -0000 From: Joel Brobecker To: Stan Shebs Cc: Aravinda , gdb@sourceware.org Subject: Re: GDB library to insert and delete watchpoints Message-ID: <20091204163819.GC2903@adacore.com> References: <26eb53620911301516x68ccc0edkf64ba2951c8ce3a3@mail.gmail.com> <26eb53620911301518y13e64bc0g95c6fe3c7b18b0c@mail.gmail.com> <4B18CD92.8000302@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B18CD92.8000302@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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-12/txt/msg00031.txt.bz2 > It just so happens that CodeSourcery recently did this for a > customer that was using a debugging stub that ran as one of several > threads in the application. This reminds me of another interesting approach that one of our customers implemented. In their setup, the software was hooked to a hardware that needed some trajectory info sent at a given frequency (about 10Hz IIRC). The problems started when they were trying to debug problems, because the debugger would stop all threads. So, what they did was implement their own gdbserver stub, embedded in their application. That stub would control start/stop etc in a way that the motion threads remain alive and kicking while the rest of the application is being inspected... AFAIK, they made it work (this was on Windows). -- Joel