From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23416 invoked by alias); 17 Oct 2008 11:59:56 -0000 Received: (qmail 23407 invoked by uid 22791); 17 Oct 2008 11:59:55 -0000 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Oct 2008 11:59:06 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 0D0902F8005; Fri, 17 Oct 2008 12:59:03 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk2+xHZPve-c; Fri, 17 Oct 2008 12:59:01 +0100 (BST) Message-ID: <48F87E04.8070000@ecoscentric.com> Date: Fri, 17 Oct 2008 11:59:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.16 (X11/20080715) MIME-Version: 1.0 To: Daniel Jacobowitz , Doug Evans , Stan Shebs CC: gdb-patches@sourceware.org, Bart Veer Subject: Re: add file I/O support when debugging an embedded target via jtag References: <48BAAC44.4000002@codesourcery.com> <20080925222009.GA8202@caradoc.them.org> <20081001210933.GA8477@caradoc.them.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2008-10/txt/msg00428.txt.bz2 Daniel, Stan and Doug Thank you for your comments on Bart Veer's original proposal and subsequent patch for file I/O support when debugging via JTAG. Proposal: http://sourceware.org/ml/gdb/2008-07/msg00045.html Patch: http://sourceware.org/ml/gdb-patches/2008-08/msg00315.html We now need to draw this to a conclusion and move on. The principle objection to the patch is that it introduces a new target ops stratum which might break other configurations or impede future developments. During our initial investigation we came to the conclusion that introducing a new stratum was the most elegant way to implement this functionality in a generic manner. In his response to the original proposal, Daniel wrote: > It's sad that you need to use the target strata for this. Doing it > directly in the remote target would work for all of the above except > for "target bdm". But I suppose it's reasonable. Is there anything we can now do to make the patch acceptable short of a re-implemention to avoid introducing a new stratum? John Dallaway eCosCentric Limited