From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23581 invoked by alias); 25 Sep 2008 20:27:27 -0000 Received: (qmail 23571 invoked by uid 22791); 25 Sep 2008 20:27:26 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Sep 2008 20:26:36 +0000 Received: from localhost (snape.ecoscentric.com [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 11DF1DC8086; Thu, 25 Sep 2008 21:26:33 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw3PnxLNOEbH; Thu, 25 Sep 2008 21:26:31 +0100 (BST) Received: from delenn.bartv.net (hagrid.vpn.ecoscentric.com [192.168.145.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 33E2BDC807F; Thu, 25 Sep 2008 21:26:31 +0100 (BST) Date: Thu, 25 Sep 2008 20:27:00 -0000 Message-Id: From: Bart Veer To: "Doug Evans" CC: stan@codesourcery.com, gdb-patches@sourceware.org In-reply-to: (dje@google.com) Subject: Re: add file I/O support when debugging an embedded target via jtag References: <48BAAC44.4000002@codesourcery.com> 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-09/txt/msg00506.txt.bz2 >>>>> "Doug" == Doug Evans writes: >> >> >>> Following on from >> >> >>> http://sourceware.org/ml/gdb-patches/2008-08/msg00315.html, >> >> >>> I have not heard anything about the code in the last two >> >> >>> weeks. Do you know if anybody is looking at it? Also, if >> >> >>> there is a likelihood that the patch will be accepted >> >> >>> then I should probably get started on the assignment >> >> >>> paperwork. Doug> My off-the-cuff thought is to see if this is something that Doug> could be handled from Python. >> >> At a high-level you are correct: when a breakpoint is hit, call >> into the existing file I/O code and then automatically resume >> the target. However a usable implementation imposes some >> additional requirements. There should be no visible output >> every time some file I/O is requested, so no messages that the >> target has halted or that there has been a thread switch. The >> overheads must be kept down as much as possible, so no >> additional register fetching, no extra memory writes to unset >> and reset breakpoints, etc. I don't think that is achievable if >> you try to do the work at the command or scripting level. Doug> There are indeed issues to be resolved, but I'd like to Doug> think these things are achievable. We can provide lots more Doug> functionality this way, not just file i/o for jtag targets Doug> (and such). >> I have not been following the Python work, but as far as I know >> it does not allow scripts to operate at the target vector >> level. That could be useful for some things, for example it >> should make it possible to add thread support for different >> embedded OS'es by writing a script instead of adding a new >> module to gdb. I suspect it will be some time before anything >> like that is possible. Doug> I shouldn't be that hard to let Python work at this level, Doug> and AIUI such things are not precluded. Although I have no doubt that a Python interface at the target vector level is possible, figuring out what such an interface should look like requires a far greater understanding of the gdb internals than I possess. I am pretty sure it would also involve much bigger changes to the internals than a one-line addition to the stratum enum. I really don't want to see the h/w debug I/O functionality to be delayed for a long time, possibly years, until all the required infrastructure is in place for a reimplementation in Python. Bart