From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cBkiHRH4O2P4TwUAWB0awg (envelope-from ) for ; Tue, 04 Oct 2022 05:08:33 -0400 Received: by simark.ca (Postfix, from userid 112) id 750D01E112; Tue, 4 Oct 2022 05:08:33 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=QeuHr+/J; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2FB011E0D5 for ; Tue, 4 Oct 2022 05:08:32 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CD5C7385C31F for ; Tue, 4 Oct 2022 09:08:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD5C7385C31F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1664874511; bh=1Z0qNmQ+6gnCME5YwyzOo4Cn+aP00mvXaE5eUW/BhTI=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=QeuHr+/J92Iv2FRcWPyIhlAcSHYNcdZbUnlQbiKzsnHYNgN5PBbSeEtG57nMzMmH7 txVQAshcRSrbLn0j3hciMdX3JGbDRnALNLAwVOOAZQEN6V3qibaAZ2ce7xVNgHO1pY Dztwti+gGVkTk2HJrfa5KGnHRScZI3flb6CQ3Zaw= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 92E0E385AC3E for ; Tue, 4 Oct 2022 09:08:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92E0E385AC3E Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-139-BU7ZzAMGOr-SYFst7aW0Fg-1; Tue, 04 Oct 2022 05:08:11 -0400 X-MC-Unique: BU7ZzAMGOr-SYFst7aW0Fg-1 Received: by mail-wr1-f71.google.com with SMTP id p7-20020adfba87000000b0022cc6f805b1so3858475wrg.21 for ; Tue, 04 Oct 2022 02:08:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=1Z0qNmQ+6gnCME5YwyzOo4Cn+aP00mvXaE5eUW/BhTI=; b=l2HGmYDcDyS4s6G0Z8hthB6WMiw5g/jc03XwG0nToWcZ469TOdQUd6fBJKamlJzxlg k5HJ1pyrzaeZs2oZazBTmOPUUEpVvl4LdSQlgr0pbdgKFU94vSx0nzaG4iwSJrIw+5k5 4AZ1arwwI/Ud9n04f7e3fQjGuvmbuowQ1GWI62EPBbfNc4+b6q9AL6ro9ojI+ggfhggB 8PlMB12Vf3+1h0eu759HB3SgFx7riWUK4+bHI3C50LmSzPG37Cll5YNPi4deIkN4JLR7 VrH82ltPHcilGgEW9a9aSDkd4WWRIhEcl5MpIQPP9yMYwWs2t4sqdpIAX/ke+vecQz2W qPmA== X-Gm-Message-State: ACrzQf3X6srqhOS4REM2oSovHtQYPeSxlEqW5POFSEpStDBLwDkiYDqU qshp5QV6CDza/eMFrPRhkoDY6ziyzFTkiZIPoceI1Sf8VEOBKG5N/ClrK95odPaJ+ySvs+GBK6S z0yKb5d+ZCuzwcnwghVcKaQ== X-Received: by 2002:a5d:4a4d:0:b0:22d:c8cb:8687 with SMTP id v13-20020a5d4a4d000000b0022dc8cb8687mr11166686wrs.554.1664874490060; Tue, 04 Oct 2022 02:08:10 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4X/1HWMdx/UBEkPbAtbcmMlKYu5ILQNPTCajY5roF3GJQmPcATNCALfUdG9JHhmVwO9wV9gA== X-Received: by 2002:a5d:4a4d:0:b0:22d:c8cb:8687 with SMTP id v13-20020a5d4a4d000000b0022dc8cb8687mr11166663wrs.554.1664874489847; Tue, 04 Oct 2022 02:08:09 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id y10-20020adffa4a000000b00228da845d4dsm12087832wrr.94.2022.10.04.02.08.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 02:08:09 -0700 (PDT) To: Pedro Alves , Lancelot SIX Subject: Re: [PATCH 1/2] gdb/testsuite: avoid creating files in gdb/testsuite directory In-Reply-To: References: <337887b9594348c5880b7adbc0850e72e319e857.1664721741.git.aburgess@redhat.com> <20221003111213.rzfci537xl3xbfkw@octopus> <87bkqshoxf.fsf@redhat.com> Date: Tue, 04 Oct 2022 10:08:08 +0100 Message-ID: <87tu4kez2f.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: , From: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Pedro Alves writes: > On 2022-10-03 5:06 p.m., Andrew Burgess via Gdb-patches wrote: >> Lancelot SIX writes: >> > >>> Just above your change, there is the following line: >>> >>> set debug_str_section "${binfile}-debug-str" >>> >>> I believe that the original intent was to use this as output file name, >>> but the '$' was use in the set args line. >>> >>> It looks to me that the change should be: >>> >>> -set args "--dump-section .debug_str=debug_str_section $binfile" >>> +set args "--dump-section .debug_str=$debug_str_section $binfile" >>> >>> If you prefer your change, the `set debug_str_section` line should be >>> removed. >> >> Good spot. >> >> Updated patch below. > > 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? 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