From: Andrew Cagney <cagney@gnu.org>
To: gdb-patches@sources.redhat.com
Subject: [rfa/testsuite] Get the inferior to dump core
Date: Mon, 20 Sep 2004 14:27:00 -0000 [thread overview]
Message-ID: <414EE841.7080908@gnu.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
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
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 5058 bytes --]
2004-09-20 Andrew Cagney <cagney@gnu.org>
* 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"
next reply other threads:[~2004-09-20 14:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 14:27 Andrew Cagney [this message]
2004-09-23 17:58 ` Michael Chastain
2004-09-23 18:29 ` Andrew Cagney
2004-09-23 19:55 ` Michael Chastain
2004-09-24 18:02 ` Andrew Cagney
2004-09-24 18:34 ` Michael Chastain
2004-09-24 19:05 ` Andrew Cagney
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=414EE841.7080908@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/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