public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Pedro Alves <palves@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] Put gdb.base/bt-on-fatal-signal.exp GDB cores in output dir
Date: Mon, 18 Jul 2022 16:31:13 +0000 (GMT)	[thread overview]
Message-ID: <20220718163113.292173858D28@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=23948f56021f46bb2bdee7afad074aafe8329230

commit 23948f56021f46bb2bdee7afad074aafe8329230
Author: Pedro Alves <pedro@palves.net>
Date:   Wed Jul 13 16:45:21 2022 +0100

    Put gdb.base/bt-on-fatal-signal.exp GDB cores in output dir
    
    I noticed that gdb.base/bt-on-fatal-signal.exp was contributing four
    core files to the count of unexpected core files:
    
     $ make check TESTS="gdb.base/bt-on-fatal-signal.exp"
    
                     === gdb Summary ===
    
     # of unexpected core files      4
     # of expected passes            21
    
    These are GDB core dumps.  They are expected, however, because the
    whole point of the testcase is to crash GDB with a signal.
    
    Make GDB change its current directory to the output dir just before
    crashing, so that the core files end up there.  The result is now:
    
                     === gdb Summary ===
    
     # of expected passes            25
    
    and:
    
     $ find . -name "core.*"
     ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1676506.nelson.1657727692
     ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1672585.nelson.1657727671
     ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1674833.nelson.1657727683
     ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1673709.nelson.1657727676
    
    (Note the test is skipped at the top if on a remote host.)
    
    Change-Id: I79e4fb2e91330279c7a509930b1952194a72e85a

Diff:
---
 gdb/testsuite/gdb.base/bt-on-fatal-signal.exp | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp b/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp
index 8adf3c4fa45..8f9d857106d 100644
--- a/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp
+++ b/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp
@@ -80,6 +80,11 @@ foreach test_data {{SEGV "Segmentation fault"} \
 	set saw_bt_end false
 	set internal_error_msg_count 0
 
+	# Get the GDB core into the output directory, so that it
+	# doesn't count as unexpected core in gdb.sum.
+	gdb_test "cd [file dirname $binfile]" "Working directory .*" \
+	    "cd to test directory"
+
 	# Send the fatal signal to GDB.
 	remote_exec host "kill -${sig} ${testpid}"


                 reply	other threads:[~2022-07-18 16:31 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220718163113.292173858D28@sourceware.org \
    --to=palves@sourceware.org \
    --cc=gdb-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).