Re: using gdb to do embedded unit/regression testing

["EBo" <ebo@sandien.com>]

Doug Evans <dje@google.com> said:

> On Mon, Nov 3, 2008 at 12:05 PM, EBo <ebo@sandien.com> wrote:
> > EBo <ebo@sandien.com> said:
> >
> >> Michael Snyder <msnyder@vmware.com> said:
> >>
> >> > EBo wrote:
> >> >
> >> > > The second issue will be cleaning up and formatting the output from the
> >> > > automated unit/regression test suites.  For this I will want/need to
> > suppress
> >> > > almost all output from gdb, and use the print command above to deal
with the
> >> > > formatting.  If I end up using gdb to help do this type of eXtreme/Agile
> >> > > program testing I would like to work with the gdb maintainers to have it
> >> > > integrated upstream...
> >> >
> >> > I think you want dejagnu.
> >
> > I will look into dejagnu, but to follow in the original thought...
> >
> > If I provided a --batch-mostly-silent switch which suppressed output for all
> > but the print, printf, and echo commands, would others find that useful?
> > Actually I should also if someone already provides this functionality before I
> > start trying to modify gdb ;-)
> 
> The new python support may/will provide the ability to redefine
> existing commands.  One can then imagine writing a wrapper that for
> the duration of the wrapper set stdout to /dev/null (figuratively
> speaking), and inserted wrappers for a collection of commands (print,
> printf, echo in your case) that for their duration set stdout ==
> /dev/stdout (figuratively speaking).
> 
> It may require a bit more support from the python/gdb interface than
> is currently there (e.g. ability to get/set the values of
> gdb_{stdout,stderr,stdlog}) , but that will be the norm for awhile.

I talked to one of my colleagues and they do not want to go the way of dejagnu
for the current project.  Also I spent quiet awhile trying to implement the
full functionality of --mostly-quiet (which boils down to if'ing out all the
trace statements but not the print* and echo output).  I was never able to
find where some of the line and break/trace output was generated.  For I am
tracking down a REALLY weird bug which implies that the version of the
cross-compiler I am running is generating bad code.  I have to focus on
sorting that out first.

  EBo --