From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17585 invoked by alias); 16 Jan 2004 19:55:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17576 invoked from network); 16 Jan 2004 19:55:33 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 16 Jan 2004 19:55:33 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 190ED2B8F; Fri, 16 Jan 2004 14:55:32 -0500 (EST) Message-ID: <400841B3.9000304@gnu.org> Date: Fri, 16 Jan 2004 19:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] new test for separate debug info References: <20031114193714.872554B3FA@berman.michael-chastain.com> <16309.13939.786088.679758@localhost.redhat.com> <16386.55063.622165.537230@localhost.redhat.com> <4003193D.3040504@gnu.org> <20040112222849.GA11269@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00422.txt.bz2 > > Ya! Now what would be nice is a similar gdbserver sniff test :-) > > > Er.... I have absolutely no idea what that sentence means :) short answer: gdb/testsuite/gdb.base/gdbserver.exp long answer: There are two ways of testing stuff like separate debug info and gdb-server: - as part of full and separate dejagnu test run eg: make check RUNTESTFLAGS=--target_board=gdbserver - as a small focused functional / unit test eg: make check RUNTESTFLAGS=gdbserver.exp Both are correct as both offer distinct advantages and disadvantages (mind you I should note that I've witnessed argument disputing this :-). The former provides better coverage, but with no realistic expectation that the average GDB developer will ever run it; while the later ensures that that specific functionality is always working, but lacks broad coverage. A gdbserver.exp unit test would significantly improve the odds of gdbserver working with a standard GDB. It would also make possible the writing of gdbserver specific tests that explore edge cases missed by the more standard tests (the attach / detach behavior for instance). Also, in support of this, even though separate debug info bit rot and broke within months of its initial commit, the breakage wasn't noticed for several further months (when the unit test was added). Andrew