[rfa/testsuite] Get the inferior to dump core

[rfa/testsuite] Get the inferior to dump core

[Andrew Cagney]

[-- 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"

Re: [rfa/testsuite] Get the inferior to dump core

[Michael Chastain]

This patch is approved.

I had wondered about that technique of bigcore.exp, it surprised me a
bit when I saw that it was making two runs of the inferior.

> Is this ok?  I just wonder if it should be generalized and moved to 
> gdb.exp, I guess that should be a separate pass.

I don't know exactly what "it" is referring to, but a separate pass
for moving "it" to gdb.exp sounds good to me.

I like what corefile.exp tries to do.  It creates a unique subdirectory
and runs the target program in the subdirectory so that the core file
is easy to find.  It suffers from build != host problems though.

Michael

===

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.

Re: [rfa/testsuite] Get the inferior to dump core

[Andrew Cagney]

> This patch is approved.

Tks, I'll commit shortly.

> I had wondered about that technique of bigcore.exp, it surprised me a
> bit when I saw that it was making two runs of the inferior.
> 
> 
>>> Is this ok?  I just wonder if it should be generalized and moved to 
>>> gdb.exp, I guess that should be a separate pass.
> 
> 
> I don't know exactly what "it" is referring to, but a separate pass
> for moving "it" to gdb.exp sounds good to me.

The sequence needed to first generate and then locate/rename a corefile 
from an inferior running under GDB (instead of running the program twice).

> I like what corefile.exp tries to do.  It creates a unique subdirectory
> and runs the target program in the subdirectory so that the core file
> is easy to find.  It suffers from build != host problems though.

but it (and I'm sure there are others) suffers from corefile != inferior 
problems and I'm pretty sure all duplicated corefile's logic.

Andrew

Re: [rfa/testsuite] Get the inferior to dump core

[Michael Chastain]

Andrew Cagney writes:
> The sequence needed to first generate and then locate/rename a corefile 
> from an inferior running under GDB (instead of running the program twice).

Okay, I'm being silly, but that reads like a patent claim to me.  :)

Seriously, that would be a good bit of code to library-ize.

Michael

Re: [rfa/testsuite] Get the inferior to dump core

[Andrew Cagney]

> Seriously, that would be a good bit of code to library-ize.

How would you like it then?  As in the, I guess proc's interface?

proc gdb_coredump_inferior ( corename msg_prefix } { ... return [01] }

Andrew

Re: [rfa/testsuite] Get the inferior to dump core

[Michael Chastain]

I'm not too worried about the interface (!), it's standardizing
the guts that I'm worried about.

  - portable way to set the core dump size to "unlimited".
    i suspect this is more portable to do at the C level with
    setrlimit() rather than the shell level with the bitter
    comments about braindamaged shells and ulimit.

  - creating a subdirectory
    corefile.exp does this at the TCL level, which immediately
    runs into a build != host problem.  Again I suspect this
    might be better to do in the inferior program:
      mkdir("coredir");
      chdir("coredir");
    coredir does not have to be unique.

  - picking up the core file
    there should be exactly ONE file in coredir.  If there are
    zero files, or two more files, then the test script cannot
    proceed.

    The problem is figuring out the name of that file.
    It's on the host machine so just "glob" will not cut it.
    I don't know if there's a "remote glob" available or what.

    After figuring out the name of the file, do remote_upload
    to get it back to the build machine to a fixed name.

That's just a half-assed look at gcore.exp.

Now, is it worth anyone's time to actually do this? 

I don't want to get into it myself because I want to get into
"user specifies which compiler to run for each language".
That's high priority and it's a big overhaul.

Re: [rfa/testsuite] Get the inferior to dump core

[Andrew Cagney]

> I'm not too worried about the interface (!), it's standardizing
> the guts that I'm worried about.

I was thinking that bigcore.exp's could be moved to gdb.exp where they 
can be used by other corefile tests with that bug - worry about fancying 
the guts if/when there's a need.

Andrew

>   - portable way to set the core dump size to "unlimited".
>     i suspect this is more portable to do at the C level with
>     setrlimit() rather than the shell level with the bitter
>     comments about braindamaged shells and ulimit.
> 
>   - creating a subdirectory
>     corefile.exp does this at the TCL level, which immediately
>     runs into a build != host problem.  Again I suspect this
>     might be better to do in the inferior program:
>       mkdir("coredir");
>       chdir("coredir");
>     coredir does not have to be unique.
> 
>   - picking up the core file
>     there should be exactly ONE file in coredir.  If there are
>     zero files, or two more files, then the test script cannot
>     proceed.
> 
>     The problem is figuring out the name of that file.
>     It's on the host machine so just "glob" will not cut it.
>     I don't know if there's a "remote glob" available or what.
> 
>     After figuring out the name of the file, do remote_upload
>     to get it back to the build machine to a fixed name.
> 
> That's just a half-assed look at gcore.exp.
> 
> Now, is it worth anyone's time to actually do this? 
> 
> I don't want to get into it myself because I want to get into
> "user specifies which compiler to run for each language".
> That's high priority and it's a big overhaul.