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.
next prev parent 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