This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Testing flash (Was: [rfa] NEWS additions for flash)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]