From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67585 invoked by alias); 19 Feb 2020 03:10:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 67576 invoked by uid 89); 19 Feb 2020 03:10:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=manage, HX-Languages-Length:1638 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 03:10:51 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 98D211E47D; Tue, 18 Feb 2020 22:10:49 -0500 (EST) Subject: Re: [PATCH v2] gdb/testsuite: Regenerate the testglue if it is not in path To: Shahab Vahedi , gdb-patches@sourceware.org Cc: Shahab Vahedi , Tom Tromey , Francois Bedard References: <20200211133710.6120-1-shahab.vahedi@gmail.com> <20200218115141.5007-1-shahab.vahedi@gmail.com> From: Simon Marchi Message-ID: <06b945ea-8287-ce1a-80de-cb33321e7da0@simark.ca> Date: Wed, 19 Feb 2020 03:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200218115141.5007-1-shahab.vahedi@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00756.txt.bz2 On 2020-02-18 6:51 a.m., Shahab Vahedi wrote: > From: Shahab Vahedi > > For running the DejaGnu tests, some esoteric configurations > may require a testglue. This, for instance, is true about > testing ARC targets which uses its own DejaGnu board and > a simulator which does not support returning the pass or fail > through the exit code. Therefore, for those tests that use When you say "returning the pass or fail through the exit code", do you mean the exit codes of the test programs (the value returned by main)? If so, it does not really mean "pass" or "fail", in a testsuite sense. In which case, it would be clearer to just say "does not support returning the program's exit code". I don't know what Tom was referring to when he talked about the cache directory. I see that the testsuite Makefile cleans a cache directory, but I have no idea how things can end up there. Tom, can you clarify? It's great if you can manage to have it built only once, but just make sure it's not racy, like: 1. Test 1 notices testglue.o is not there 2. Test 2 notices testglue.o is not there 3. Test 1 generates testglue.o 4. Test 2 starts to write testglue.o, deleting what was done in step 3, gets interrupted half-way 5. Test 1 tries to link the half-baked testglue.o in its executable and fails An option to have it at a predictable absolute place would be to pass the result of [standard_output_file testglue.o] to build_wrapper. It would be rebuilt for each test, but it would make sure that tests don't interfere with each other. Simon