From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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) From: Andrew Burgess To: Pedro Alves , Lancelot SIX Cc: gdb-patches@sourceware.org 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-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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 09:08:13 -0000 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