From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by sourceware.org (Postfix) with ESMTPS id D0D613858407 for ; Tue, 4 Oct 2022 12:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D0D613858407 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f41.google.com with SMTP id j7so15663575wrr.3 for ; Tue, 04 Oct 2022 05:15:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date; bh=NYvlQlV1Eln2P7CDvOr3Va062s8TnyweLaD+jxsume4=; b=vcbJmJ7/BwLfGasNDB6RiRhPa1qutn4ho+pkm2X3QjPsADXK+wZYLl8Fyh2ODueZY4 vHH8SAoz/oHCpXSDAJE6HPxt8iVPVkFw7zABrBZvDzw2bwPnZ8CcwbEEGRgWdbgPxGva +3bVpRveNCLD29GbPch7sJ1xI0718HzknOaXf58g6XHznGl4w4HvdiNdwpP71ZFaGhSc 0m1jIvPxc9IzIxYH0MUTHpBhdo0wa8XQ4YiCex4KOlzjQLeq2/jkvzQ5EVABQA92sOgZ wjsDwLvYlOVtSeb3VdiruezU8A9/6lyoPiDRi/MtTzLZ3xTAJ/pNo42c7+0O9CZcNnJg PozQ== X-Gm-Message-State: ACrzQf3Clts+c6cb/+dLLzANu62f7CdY+9wIYb9obI9PeKKqp8fhAtk1 GU1NMQqXzdeJdbZWE7CoIIyh42g6/Jk= X-Google-Smtp-Source: AMsMyM4QmMUe36J15GnZfeOdFYIIAebxMD4fu5PXmpA142DZy/UKAaXyjXKnNKb+kPJTllxWsmmQxA== X-Received: by 2002:adf:f90d:0:b0:20c:de32:4d35 with SMTP id b13-20020adff90d000000b0020cde324d35mr16089361wrr.583.1664885741158; Tue, 04 Oct 2022 05:15:41 -0700 (PDT) Received: from ?IPv6:2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653? ([2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653]) by smtp.gmail.com with ESMTPSA id c13-20020adfed8d000000b0022dc6e76bbdsm11800240wro.46.2022.10.04.05.15.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Oct 2022 05:15:40 -0700 (PDT) Subject: Re: [PATCH 1/2] gdb/testsuite: avoid creating files in gdb/testsuite directory To: Andrew Burgess , Lancelot SIX Cc: gdb-patches@sourceware.org References: <337887b9594348c5880b7adbc0850e72e319e857.1664721741.git.aburgess@redhat.com> <20221003111213.rzfci537xl3xbfkw@octopus> <87bkqshoxf.fsf@redhat.com> <87tu4kez2f.fsf@redhat.com> From: Pedro Alves Message-ID: <6e413cc2-b70b-d769-d607-fbe609c6607a@palves.net> Date: Tue, 4 Oct 2022 13:15:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87tu4kez2f.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2022 12:15:45 -0000 On 2022-10-04 10:08 a.m., Andrew Burgess wrote: > Pedro Alves writes: >> I'm glad you guys found this alternative approach. I was going to suggest >> to see if we could avoid changing directory, the "cd" approach IMO should be >> avoided if possible. The reason is that when you change gdb's directory to >> the test's output dir, if GDB crashes and produces a core on teardown, then that core will >> end up in the test's output directory, and thus won't be noticed by the spurious core >> detection, i.e., won't be signaled in gdb.sum. > > What if I added a mechanism to lib/gdb.exp that allowed for something > like: > > with_change_gdb_directory $some_directory { > # A set of tests here... > } > > and had the with_change_gdb_directory proc check that GDB was still > running at the end of the block. > > This way, when the test script ends, and GDB is shutdown, we will always > be back in the original directory, so a crash on teardown will be > spotted (via the coredump). > > And if GDB crashes during the inner block, then yes, the coredump will > be in the "wrong" place, but we should be guaranteed to see a test > failure. > > Would something like this be acceptable? Yes, I think that is sufficient in practice. I'm happy with that. Thanks, Pedro Alves > > My other idea is to have 'maint selftest' take an extra argument like: > > (gdb) maint selftest --temp-directory /path/to/directory > > which would then be used by the individual tests when creating temporary > files. > > Thoughts? > > Thanks, > Andrew >