From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8132 invoked by alias); 20 May 2013 14:39:02 -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 8123 invoked by uid 89); 20 May 2013 14:39:02 -0000 X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 20 May 2013 14:39:02 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4KEd0Yx025089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 May 2013 10:39:00 -0400 Received: from barimba (ovpn-113-72.phx2.redhat.com [10.3.113.72]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4KEcxk7028739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 10:39:00 -0400 From: Tom Tromey To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [WIP] TI msp430 CIO support References: <20130516212358.23f3bcdb@mesquite.lan> Date: Mon, 20 May 2013 14:39:00 -0000 In-Reply-To: <20130516212358.23f3bcdb@mesquite.lan> (Kevin Buettner's message of "Thu, 16 May 2013 21:23:58 -0700") Message-ID: <87ip2dogvw.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-05/txt/msg00727.txt.bz2 >>>>> "Kevin" == Kevin Buettner writes: Kevin> The debugger based driver uses a simple breakpoint driven Kevin> implementation. The debugger places a breakpoint on a known location Kevin> which is always called when debugger-based I/O is to be performed. Kevin> When the breakpoint at that location is hit, the debugger reads the Kevin> details of the system call and its parameters from a memory based Kevin> buffer. The debugger writes back the output of the system call to the Kevin> same buffer. (See my patch for the exact details.) I was also curious why this wasn't done on the stub side and just have the stub emit the output packets. Kevin> One of my early implementations of this functionality used a normal Kevin> (but hidden) GDB breakpoint with a command list whose last command Kevin> was "continue". This is similar to the way that dprintf is implemented. Another way is to have a hidden breakpoint and override its check_status breakpoint_ops method. Then, have this method always set bs->stop = 0. This won't work for dprintf, since dprintf wants various user-visible breakpoint tweaks to also work; but I think it would work fine for your case. Tom