From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14400 invoked by alias); 6 Nov 2008 17:14:21 -0000 Received: (qmail 14321 invoked by uid 22791); 6 Nov 2008 17:14:20 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 17:13:44 +0000 Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id mA6HDfoM000537 for ; Thu, 6 Nov 2008 09:13:42 -0800 Received: from rv-out-0506.google.com (rvbg37.prod.google.com [10.140.83.37]) by wpaz37.hot.corp.google.com with ESMTP id mA6HDeIH007851 for ; Thu, 6 Nov 2008 09:13:40 -0800 Received: by rv-out-0506.google.com with SMTP id g37so748435rvb.23 for ; Thu, 06 Nov 2008 09:13:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.132.4 with SMTP id f4mr1319642rvd.46.1225991620090; Thu, 06 Nov 2008 09:13:40 -0800 (PST) In-Reply-To: References: <490F4EAB.206@vmware.com> Date: Thu, 06 Nov 2008 17:14:00 -0000 Message-ID: Subject: Re: using gdb to do embedded unit/regression testing From: Doug Evans To: ebo@sandien.com Cc: Michael Snyder , "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00058.txt.bz2 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.