Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <Michael.Snyder@palmsource.com>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Testing flash (Was: [rfa] NEWS additions for flash)
Date: Fri, 22 Sep 2006 17:55:00 -0000	[thread overview]
Message-ID: <1158947693.22863.61.camel@localhost.localdomain> (raw)
In-Reply-To: <eevve1$pp6$1@sea.gmane.org>

On Fri, 2006-09-22 at 10:23 +0400, Vladimir Prus wrote:
> Daniel Jacobowitz wrote:
> 
> > On Thu, Sep 21, 2006 at 12:10:56PM -0700, Michael Snyder wrote:
> >> On Thu, 2006-09-21 at 10:18 -0400, Daniel Jacobowitz wrote:
> >> > This patch adds news entries for the flash patches I've just checked
> >> > in.  Is this OK?
> >> > 
> >> > The next release is shaping up to be quite an improvement.
> >> 
> >> On a quick scan of your (today's) patch, I don't see any tests.
> >> Is this testable?
> > 
> > In theory, you could write some tests for it using 'gdbreplay'.  But
> > getting gdbreplay to work in the testsuite harness would be quite
> > tricky, and it would be complicated by the fact that which registers
> > GDB asks for at connection is target dependent; I don't know how to
> > write generic remote protocol tests.
> > 
> > I'd love to unit test this stuff.  If you have any suggestions, I'm
> > all ears.
> 
> Assuming not everybody has boards with flash handy, and burning flash every
> night is bad idea, we need some 'fake' setup anyway. For example, we can
> take any remote test and then:
> 
>   - Fabricate memory map that has flash regions. Such memory map can
>     be fixed, having no relation to actual remote target. 
>   - Log all flash packets without passing them to remote side.
> 
> I think we can either have special 'flash debug mode' in gdb, which reads
> memory map from a file you specify and writes flash packages to another
> file you specify, or man-in-the-middle between gdb and real remote that
> does the same. I'd suspect adding flash debug mode in gdb would be simpler.
> 
> Ah, and I supposed that if we want to match generated flash packets to
> expectation, we need to 'load' a fixed *binary* -- not binary produced from
> sources, but a binary added to CVS.

I'm very interested in general in this kind of "fake" debugging, 
essentially for testing purposes.  E.g. that we could make up a
hacked version of gdbserver that would give back some packet
responses that immitated services that it was not actually able
to provide.


  reply	other threads:[~2006-09-22 17:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-21 14:18 [rfa] NEWS additions for flash Daniel Jacobowitz
2006-09-21 19:11 ` Michael Snyder
2006-09-21 19:14   ` Daniel Jacobowitz
2006-09-21 21:00     ` Michael Snyder
2006-09-22  6:22     ` Testing flash (Was: [rfa] NEWS additions for flash) Vladimir Prus
2006-09-22 17:55       ` Michael Snyder [this message]
2006-09-22 12:06 ` [rfa] NEWS additions for flash Eli Zaretskii
2007-01-21 17:49   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1158947693.22863.61.camel@localhost.localdomain \
    --to=michael.snyder@palmsource.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox