From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90930 invoked by alias); 7 Mar 2018 03:08:52 -0000 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 Received: (qmail 90014 invoked by uid 89); 7 Mar 2018 03:08:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=steal, highly X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Mar 2018 03:08:49 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w2738hWP005661 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 6 Mar 2018 22:08:47 -0500 Received: by simark.ca (Postfix, from userid 112) id CED6B1E662; Tue, 6 Mar 2018 22:08:42 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 13B321E018; Tue, 6 Mar 2018 22:08:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 07 Mar 2018 03:08:00 -0000 From: Simon Marchi To: Andrey Utkin Cc: gdb@sourceware.org, Yao Qi Subject: Re: Help request on making a gdb testsuite case In-Reply-To: <20180306180136.GA27627@undo-autkin> References: <20180306180136.GA27627@undo-autkin> Message-ID: <63360d7d22beacf3f3fcd144026bf89b@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 7 Mar 2018 03:08:43 +0000 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00021.txt.bz2 On 2018-03-06 13:01, Andrey Utkin wrote: > Hi GDB devs, > > I have found that the case of restarting the debuggee in > extended-remote > session has been broken in GDB for undetermined, but quite long time > (predating gdb 7.10.1). > > It got fixed in git master just recently, on February 15 by Yao Qi in > commit 85046ae23f85 (thanks a lot!). Anyway, now I have an automated > way > to detect the bug which got fixed, and would like to turn it into a > case > in GDB test suite. > > # "./simple" is built from "int main(){return 0;}", must be unstripped > timeout 4 "$GDB" \ > -ex "target extended-remote | $GDBSERVER --once - ./simple" \ > -ex 'break main' \ > -ex 'set confirm off' \ > -ex 'run' \ > -ex 'quit' \ > ; > # buggy gdb would hang > > It is not obvious to me how to write such a testcase. There are three > elements: the debuggee, the server process and the frontend process. I > have very rough idea that some goodness to use is in > lib/gdbserver-support.exp, and almost certainly i'll use gdb_target_cmd > procedure, but beyond that, I'm pretty much lost. How would I specify a > debuggee program, or where do I find one to reuse after other tests? > > Any help would be highly appreciated! Hi Andrey, I'm a bit surprised that we don't already have a test that tries re-running an inferior. I ran the testsuite before and after that patch, and didn't see result change, so maybe we are indeed missing one to test this. Normally, test cases don't care whether they are ran against a gdb that debugs natively or a gdb that connects to gdbserver. That is controlled when running the testsuite. By default, the testsuite will use a gdb that debugs natively, but when passing RUNTESTFLAGS="--target_board=native-extended_gdbserver", for example, it will use a gdb connected to a gdbserver (on localhost) with the extended-remote protocol. I could only reproduce the bug when starting gdbserver with a binary file. However, with the native-extended-gdbserver board, gdbserver is started with --multi and no binary file specified. If we absolutely need to start gdbserver with non-standard arguments to reproduce the bug, then we would have to write a gdbserver-specific test and put it in testsuite/gdb.server. I suggest you look at the other files in this directory and steal some bits from them. You can then ask further questions about the bumps you hit (here, or on IRC). Here are some details about running the tests: https://sourceware.org/gdb/wiki/TestingGDB Here are some details about writing tests: https://sourceware.org/gdb/wiki/GDBTestcaseCookbook Simon