From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23527 invoked by alias); 6 Nov 2008 17:23:16 -0000 Received: (qmail 23454 invoked by uid 22791); 6 Nov 2008 17:23:15 -0000 X-Spam-Check-By: sourceware.org Received: from mx1a.swcp.com (HELO mx1a.swcp.com) (216.184.2.64) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 17:22:31 +0000 Received: from ame8.swcp.com (ame8.swcp.com [216.184.2.163]) by mx1a.swcp.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id mA6HMTB1010452 for ; Thu, 6 Nov 2008 10:22:29 -0700 Received: from swcp.com (nousagi.swcp.com [216.184.2.107] (may be forged)) by ame8.swcp.com (8.14.2/8.13.6) with SMTP id mA6HMRhd037972 for ; Thu, 6 Nov 2008 10:22:27 -0700 (MST) (envelope-from ebo@sandien.com) Date: Thu, 06 Nov 2008 17:23:00 -0000 To: Subject: Re: using gdb to do embedded unit/regression testing From: "EBo" X-Mailer: TWIG 2.7.7 Message-ID: In-Reply-To: References: <490F4EAB.206@vmware.com> , X-Client-IP: 216.184.15.167 Cc: "gdb@sourceware.org" Reply-To: ebo@sandien.com X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (ame8.swcp.com [216.184.2.128]); Thu, 06 Nov 2008 10:22:27 -0700 (MST) X-Virus-Status: Clean Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00059.txt.bz2 Doug Evans said: > On Mon, Nov 3, 2008 at 12:05 PM, EBo wrote: > > EBo said: > > > >> Michael Snyder 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 --