From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10878 invoked by alias); 24 Sep 2008 21:21:41 -0000 Received: (qmail 10868 invoked by uid 22791); 24 Sep 2008 21:21:40 -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; Wed, 24 Sep 2008 21:20:42 +0000 Received: from localhost (snape.ecoscentric.com [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 35BF0DC8D07; Wed, 24 Sep 2008 22:20:39 +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 zFWn7JdkXnvb; Wed, 24 Sep 2008 22:20:37 +0100 (BST) Received: from delenn.bartv.net (hagrid.vpn.ecoscentric.com [192.168.145.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 7C202DC807F; Wed, 24 Sep 2008 22:20:37 +0100 (BST) Date: Wed, 24 Sep 2008 21:21: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/msg00494.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. Stan> To be honest, I looked at it but didn't understand why all Stan> this stuff seemed necessary. If this is not for the remote Stan> protocol, then what is it for? A target supported by GDB, or Stan> something else? Bart> The rationale was given in Bart> http://sourceware.org/ml/gdb/2008-07/msg00045.html >> >> >> >> Just wondering if you had had a chance to take another look at this. >> It has now been six weeks since the original posting. Doug> Hi. fwiw, I've read the patch and past emails. fwiw, I love Doug> the idea but wonder if it should be done differently. Adding Doug> a new stratum feels wrong to me too. But maybe I'm missing Doug> something so let me first ask a question. Basically all you Doug> need is a way to run some special code when a particular Doug> breakpoint is hit, right? [There's some housekeeping like Doug> needing to intercept program loads (IIRC), but basically the Doug> high order bit is running special code when a particular Doug> breakpoint is hit, right?] I'm just wondering if this can be Doug> done differently without being as invasive on GDB's innards. 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. 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. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ** Visit us on stand 905 at the Embedded Systems Show 2008 ** ** Oct 1-2, NEC, Birmingham, UK http://www.embedded.co.uk **