From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9541 invoked by alias); 20 Sep 2004 14:27:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9533 invoked from network); 20 Sep 2004 14:27:26 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 20 Sep 2004 14:27:26 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8KERLnq022822 for ; Mon, 20 Sep 2004 10:27:26 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8KERKr28098; Mon, 20 Sep 2004 10:27:21 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4319928D2; Mon, 20 Sep 2004 10:25:05 -0400 (EDT) Message-ID: <414EE841.7080908@gnu.org> Date: Mon, 20 Sep 2004 14:27:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [rfa/testsuite] Get the inferior to dump core Content-Type: multipart/mixed; boundary="------------050009000902010401000902" X-SW-Source: 2004-09/txt/msg00312.txt.bz2 This is a multi-part message in MIME format. --------------050009000902010401000902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 888 Hello, I'm encountering systems where repeated program runs yield different results (PIE and the like). This means that the bigcore.exp (other tests as well?) technique of: - run program, dump core - debug program, capture state - debug core, compare state doesn't work - the corefile and debug inferior being separate program runs can yeild different results. The attached changes bigcore.exp so that it causes the running inferior to dump core (instead of creating a new process) so that the results are identical: - debug program, capture state - core dump inferior - debug core, compare state It now also prints UNTESTED for any case where the test is aborted. It was printing either warning or xfail :-/ Is this ok? I just wonder if it should be generalized and moved to gdb.exp, I guess that should be a separate pass. Tested on an amd64 GNU/Linux system. Andrew --------------050009000902010401000902 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 5058 2004-09-20 Andrew Cagney * gdb.base/bigcore.exp: Replace the code that creates a corefile from a separate process with code that creates a corefile by making the inferior dump core. Index: gdb.base/bigcore.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.exp,v retrieving revision 1.8 diff -p -u -r1.8 bigcore.exp --- gdb.base/bigcore.exp 16 Sep 2004 05:23:13 -0000 1.8 +++ gdb.base/bigcore.exp 20 Sep 2004 14:26:16 -0000 @@ -65,36 +65,6 @@ if { [gdb_compile "${srcdir}/${subdir}/ gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." } -# Create a core file named "TESTFILE.corefile" rather than just -# "core", to avoid problems with sys admin types that like to -# regularly prune all files named "core" from the system. - -# Some systems append "core" to the name of the program; others append -# the name of the program to "core"; still others (like Linux, as of -# May 2003) create cores named "core.PID". In the latter case, we -# could have many core files lying around, and it may be difficult to -# tell which one is ours, so let's run the program in a subdirectory. - -set found 0 -set coredir "${objdir}/${subdir}/coredir.[getpid]" -file mkdir $coredir -catch "system \"(cd ${coredir}; ${binfile}; true) >/dev/null 2>&1\"" -set names [glob -nocomplain -directory $coredir *core*] -if {[llength $names] == 1} { - set file [file join $coredir [lindex $names 0]] - remote_exec build "mv $file $corefile" - set found 1 -} - -# Try to clean up after ourselves. -remote_file build delete [file join $coredir coremmap.data] -remote_exec build "rmdir $coredir" - -if { $found == 0 } { - warning "can't generate a core file - core tests suppressed - check ulimit -c" - return 0 -} - # Run GDB on the bigcore program up-to where it will dump core. gdb_exit @@ -113,28 +83,6 @@ gdb_test "tbreak $print_core_line" gdb_test continue ".*print_string.*" gdb_test next ".*0 = 0.*" -# Check that the corefile is plausibly large enough. We're trying to -# detect the case where the operating system has truncated the file -# just before signed wraparound. TCL, unfortunately, has a similar -# problem - so use catch. It can handle the "bad" size but not necessarily -# the "good" one. And we must use GDB for the comparison, similarly. - -if {[catch {file size $corefile} core_size] == 0} { - set core_ok 0 - gdb_test_multiple "print bytes_allocated < $core_size" "check core size" { - -re " = 1\r\n$gdb_prompt $" { - pass "check core size" - set core_ok 1 - } - -re " = 0\r\n$gdb_prompt $" { - xfail "check core size (system does not support large corefiles)" - } - } - if {$core_ok == 0} { - return 0 - } -} - # Traverse part of bigcore's linked list of memory chunks (forward or # backward), saving each chunk's address. @@ -170,6 +118,71 @@ proc extract_heap { dir } { set next_heap [extract_heap next] set prev_heap [extract_heap prev] +# Now create a core dump + +# Rename the core file to "TESTFILE.corefile" rather than just "core", +# to avoid problems with sys admin types that like to regularly prune +# all files named "core" from the system. + +# Some systems append "core" to the name of the program; others append +# the name of the program to "core"; still others (like Linux, as of +# May 2003) create cores named "core.PID". + +# Save the process ID. Some systems dump the core into core.PID. +set test "grab pid" +gdb_test_multiple "info program" $test { + -re "child process (\[0-9\]+).*$gdb_prompt $" { + set inferior_pid $expect_out(1,string) + pass $test + } + -re "$gdb_prompt $" { + set inferior_pid unknown + pass $test + } +} + +# Dump core using SIGABRT +set oldtimeout $timeout +set timeout 600 +gdb_test "signal SIGABRT" "Program terminated with signal SIGABRT, .*" + +# Find the corefile +set file "" +foreach pat [list core.${inferior_pid} ${testfile}.core core] { + set names [glob -nocomplain $pat] + if {[llength $names] == 1} { + set file [lindex $names 0] + remote_exec build "mv $file $corefile" + break + } +} + +if { $file == "" } { + untested "Can't generate a core file" + return 0 +} + +# Check that the corefile is plausibly large enough. We're trying to +# detect the case where the operating system has truncated the file +# just before signed wraparound. TCL, unfortunately, has a similar +# problem - so use catch. It can handle the "bad" size but not +# necessarily the "good" one. And we must use GDB for the comparison, +# similarly. + +set core_ok 0 +if {[catch {file size $corefile} core_size] == 0} { + gdb_test_multiple "print bytes_allocated < $core_size" "check core size" { + -re " = 1\r\n$gdb_prompt $" { + pass "check core size" + set core_ok 1 + } + } +} +if {$core_ok == 0} { + untested "check core size (system does not support large corefiles)" + return 0 +} + # Now load up that core file set test "load corefile" --------------050009000902010401000902--