From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3211 invoked by alias); 25 Sep 2008 17:05:20 -0000 Received: (qmail 3197 invoked by uid 22791); 25 Sep 2008 17:05:19 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Sep 2008 17:04:28 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id m8PH4Nge007572 for ; Thu, 25 Sep 2008 18:04:24 +0100 Received: from rv-out-0506.google.com (rvbf9.prod.google.com [10.140.82.9]) by wpaz21.hot.corp.google.com with ESMTP id m8PH4LVK027716 for ; Thu, 25 Sep 2008 10:04:22 -0700 Received: by rv-out-0506.google.com with SMTP id f9so17139rvb.7 for ; Thu, 25 Sep 2008 10:04:21 -0700 (PDT) Received: by 10.141.116.17 with SMTP id t17mr4220301rvm.251.1222362261750; Thu, 25 Sep 2008 10:04:21 -0700 (PDT) Received: by 10.141.99.20 with HTTP; Thu, 25 Sep 2008 10:04:21 -0700 (PDT) Message-ID: Date: Thu, 25 Sep 2008 17:05:00 -0000 From: "Doug Evans" To: "Bart Veer" Subject: Re: add file I/O support when debugging an embedded target via jtag Cc: stan@codesourcery.com, gdb-patches@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48BAAC44.4000002@codesourcery.com> X-IsSubscribed: yes 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/msg00505.txt.bz2 On Wed, Sep 24, 2008 at 2:20 PM, Bart Veer wrote: >>>>>> "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. There are indeed issues to be resolved, but I'd like to think these things are achievable. We can provide lots more functionality this way, not just file i/o for jtag targets (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. I shouldn't be that hard to let Python work at this level, and AIUI such things are not precluded.