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 9C0833854151 for ; Tue, 4 Oct 2022 14:20:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C0833854151 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-651-CIxp1d69P5OFzscshDL7-w-1; Tue, 04 Oct 2022 10:20:21 -0400 X-MC-Unique: CIxp1d69P5OFzscshDL7-w-1 Received: by mail-wr1-f69.google.com with SMTP id g15-20020adfbc8f000000b0022a4510a491so4164849wrh.12 for ; Tue, 04 Oct 2022 07:20:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=bZociQCR88y9sAsnLE3EDMvw5lA/qUEUhn4KYorUlEw=; b=zT9E/cDjDVfpBqSTMq1XqRvffMhMXdvThHWfELIp5OZg+7ex8Xalvh7JN0pZMhi+wj Jz0bvL7AcLamy+z0k3IK2J+oCEFe2iuNVzWeSMqtsZj8RbNDZQfQFT4cqeKlBWe/UAbJ kfxyAbOA7ROUTNf3pKvhgTQoFJWyLdA94baqKu3eydK7uASsc9SUh5KnVDtyyDOkVnkN Vd7/cJUl3c66gk0LJ6JwMtCxN2mxXznNQJvra3Tm9h6yorMnxSS75VicoZU4Qt1x/HQe 6++bAjjF/UXCMmzIUHVZ5sLHd7QmAtrZ+f1okVYJtAPM/PNIIa9cZ7WjARvxedzZCYJy YLmQ== X-Gm-Message-State: ACrzQf2sOl2RO8c/8x/H0QFdOa2t+63uB+xEEcvUoABgEuFrd4Li0nyI NrUUqXWVNVsqXLL0YSj66zopeB+R8vRGcm/iysl361BKzIwgEkyo6wFBWo/OrJPinqDkDF3Zjie E6G1Yd8rJ71Bzw536Rxd7XsOoEYm0CvW+Qd5kqn9r/sVQ7pc6QKArutkqhCxV04D5OXrOuXJ56w == X-Received: by 2002:a05:6000:156e:b0:226:f190:448b with SMTP id 14-20020a056000156e00b00226f190448bmr16873755wrz.573.1664893220087; Tue, 04 Oct 2022 07:20:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7M8jqGGouzBljZ/HBYrgS9Y2D7m2gYryCoSxrv3KfQ7nrfWKkpsJK/S6D/xa9/6G7Y+2viiw== X-Received: by 2002:a05:6000:156e:b0:226:f190:448b with SMTP id 14-20020a056000156e00b00226f190448bmr16873731wrz.573.1664893219706; Tue, 04 Oct 2022 07:20:19 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id w10-20020a05600c474a00b003b4ac05a8a4sm25602975wmo.27.2022.10.04.07.20.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 07:20:19 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Subject: [PATCHv2 2/2] gdb/testsuite: avoid temporary file in gdb/testsuite (unittest.exp) Date: Tue, 4 Oct 2022 15:20:14 +0100 Message-Id: <1078b31a3a4dc1133b6d734480bc7f2383510e19.1664893145.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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 14:20:25 -0000 I spotted that the gdb.gdb/unittest.exp script causes a temporary file inserters_extractors-2.txt to be created in build/gdb/testsuite/ instead of in build/gdb/testsuite/output/gdb.gdb/unittest/. This is because some of the 'maint selftest' tests create temporary files in GDB's current directory, specifically, the two source files: gdb/unittests/basic_string_view/inserters/wchar_t/2.cc gdb/unittests/basic_string_view/inserters/char/2.cc both create a temporary file called inserters_extractors-2.txt, though we only run the second of these as part of GDB's selftests. I initially proposed just using GDB's 'cd' command in unittest.exp to switch to the test output directory before running the selftests, however, Pedro pointed out that there was a risk here that, if GDB crashed during shutdown, the generated core file would be left in the test output directory rather than in the testsuite directory. As a result, our clever core file spotting logic would fail to spot the core file and alert the user. Instead, I propose this slightly more involved solution. I've added a new with_gdb_cwd directory proc, used like this: with_gdb_cwd $directory { # Tests here... } The new proc temporarily switches to $directory and then runs the tests within the block. After running the tests the previous current working directory is restored. Additionally, after switching back to the previous cwd, we check that GDB is still responsive. This means that if GDB crashed immediately prior to restoring the previous directory, and left the core file in the wrong place, then the responsiveness check will fail, and a FAIL will be emitted, this should be enough to alert the user that something has gone wrong. With this commit in place the unittest.exp script now leaves its temporary file in the test output directory. --- gdb/testsuite/gdb.gdb/unittest.exp | 46 +++++++----- gdb/testsuite/lib/gdb.exp | 110 +++++++++++++++++++++++++++++ 2 files changed, 137 insertions(+), 19 deletions(-) diff --git a/gdb/testsuite/gdb.gdb/unittest.exp b/gdb/testsuite/gdb.gdb/unittest.exp index 2967b994cc3..fdae7a24632 100644 --- a/gdb/testsuite/gdb.gdb/unittest.exp +++ b/gdb/testsuite/gdb.gdb/unittest.exp @@ -40,26 +40,34 @@ proc run_selftests { binfile } { clean_restart ${binfile} } + # Some of the selftests create temporary files in GDB's current + # directory. So, while running the selftests, switch to the + # test's output directory to avoid leaving clutter in the + # gdb/testsuite root directory. + set dir [standard_output_file ""] set enabled 1 - set test "maintenance selftest" - gdb_test_multiple $test $test { - -re ".*Running selftest \[^\n\r\]+\." { - # The selftests can take some time to complete. To prevent - # timeout spot the 'Running ...' lines going past, so long as - # these are produced quickly enough then the overall test will - # not timeout. - exp_continue - } - -re "Ran ($decimal) unit tests, ($decimal) failed\r\n$gdb_prompt $" { - set num_ran $expect_out(1,string) - set num_failed $expect_out(2,string) - gdb_assert "$num_ran > 0" "$test, ran some tests" - gdb_assert "$num_failed == 0" "$test, failed none" - } - -re "Selftests have been disabled for this build.\r\n$gdb_prompt $" { - unsupported $test - set num_ran 0 - set enabled 0 + set num_ran 0 + with_gdb_cwd $dir { + set test "maintenance selftest" + gdb_test_multiple $test $test { + -re ".*Running selftest \[^\n\r\]+\." { + # The selftests can take some time to complete. To prevent + # timeout spot the 'Running ...' lines going past, so long as + # these are produced quickly enough then the overall test will + # not timeout. + exp_continue + } + -re "Ran ($decimal) unit tests, ($decimal) failed\r\n$gdb_prompt $" { + set num_ran $expect_out(1,string) + set num_failed $expect_out(2,string) + gdb_assert "$num_ran > 0" "$test, ran some tests" + gdb_assert "$num_failed == 0" "$test, failed none" + } + -re "Selftests have been disabled for this build.\r\n$gdb_prompt $" { + unsupported $test + set num_ran 0 + set enabled 0 + } } } diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 432ed5e34ca..5a2b176afec 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -2761,6 +2761,116 @@ proc with_cwd { dir body } { } } +# Use GDB's 'cd' command to switch to DIR. Return true if the switch +# was successful, otherwise, call perror and return false. + +proc gdb_cd { dir } { + set new_dir "" + gdb_test_multiple "cd $dir" "" { + -re "^cd \[^\r\n\]+\r\n" { + exp_continue + } + + -re "^Working directory (\[^\r\n\]+)\\.\r\n" { + set new_dir $expect_out(1,string) + exp_continue + } + + -re "^$::gdb_prompt $" { + if { $new_dir == "" || $new_dir != $dir } { + perror "failed to switch to $dir" + return false + } + } + } + + return true +} + +# Use GDB's 'pwd' command to figure out the current working directory. +# Return the directory as a string. If we can't figure out the +# current working directory, then call perror, and return the empty +# string. + +proc gdb_pwd { } { + set dir "" + gdb_test_multiple "pwd" "" { + -re "^pwd\r\n" { + exp_continue + } + + -re "^Working directory (\[^\r\n\]+)\\.\r\n" { + set dir $expect_out(1,string) + exp_continue + } + + -re "^$::gdb_prompt $" { + } + } + + if { $dir == "" } { + perror "failed to read GDB's current working directory" + } + + return $dir +} + +# Similar to the with_cwd proc, this proc runs BODY with the current +# working directory changed to CWD. +# +# Unlike with_cwd, the directory change here is done within GDB +# itself, so GDB must be running before this proc is called. + +proc with_gdb_cwd { dir body } { + set saved_dir [gdb_pwd] + if { $saved_dir == "" } { + return + } + + verbose -log "Switching to directory $dir (saved CWD: $saved_dir)." + if ![gdb_cd $dir] { + return + } + + set code [catch {uplevel 1 $body} result] + + verbose -log "Switching back to $saved_dir." + if ![gdb_cd $saved_dir] { + return + } + + # Check that GDB is still alive. If GDB crashed in the above code + # then any corefile will have been left in DIR, not the root + # testsuite directory. As a result the corefile will not be + # brought to the users attention. Instead, if GDB crashed, then + # this check should cause a FAIL, which should be enough to alert + # the user. + set saw_result false + gdb_test_multiple "p 123" "" { + -re "p 123\r\n" { + exp_continue + } + + -re "^\\\$$::decimal = 123\r\n" { + set saw_result true + exp_continue + } + + -re "^$::gdb_prompt $" { + if { !$saw_result } { + fail "check gdb is alive in with_gdb_cwd" + } + } + } + + if {$code == 1} { + global errorInfo errorCode + return -code $code -errorinfo $errorInfo -errorcode $errorCode $result + } else { + return -code $code $result + } +} + # Run tests in BODY with GDB prompt and variable $gdb_prompt set to # PROMPT. When BODY is finished, restore GDB prompt and variable # $gdb_prompt. -- 2.25.4