OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Revert previous change --- the hour was late, and I was confused about 

its status.
This commit is contained in:
Jim Blandy 2002-11-22 19:07:28 +00:00
parent 7a67d0fe2b
commit f81a4d0bea
3 changed files with 0 additions and 75 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
gdb/testsuite/ChangeLog
View File

@ -1,14 +1,3 @@
2002-11-22 Jim Blandy <jimb@redhat.com>
* gdb.base/step-line.exp: Check that GDB can handle filenames that
appear in the line number info, but not in the preprocessor macro
info.
* lib/gdb.exp (gdb_internal_error_regexp): New variable.
(gdb_internal_error_resync): New procedure.
(gdb_test): If the command results in an internal error,
answer GDB's questions until we get back to a prompt.
2002-11-21 Daniel Jacobowitz <drow@mvista.com>
* gdb.base/maint.exp (help maint dump-me): Update with typo fix.

9
gdb/testsuite/gdb.base/step-line.exp
View File

@ -53,15 +53,6 @@ gdb_test "continue" \
gdb_test "next" \
".*i = f2 \\(i\\);.*" \
"next over dummy 1"
# As of Oct 2002, GCC does record the effect of #line directives in
# the source line info, but not in macro info. This means that GDB's
# symtabs (built from the former, among other things) may mention
# filenames that GDB's macro tables (built from the latter) don't have
# any record of. Make sure GDB can handle this by trying to evaluate
# an expression, which will do a macro expansion.
gdb_test "print i" ".* = 4.*"
gdb_test "next" \
".*dummy \\(2, i\\);.*" \
"next to dummy 2"

55
gdb/testsuite/lib/gdb.exp
View File

@ -370,56 +370,6 @@ proc gdb_continue_to_breakpoint {name} {
}
# A regular expression matching the output GDB produces when it
# reports an internal error.
set gdb_internal_error_regexp ".*A problem internal to GDB has been detected"
# gdb_internal_error_resync TESTNAME
#
# Answer the questions GDB asks after it reports an internal error
# until we get back to a GDB prompt, as part of the test named
# TESTNAME. Decline to quit the debugging session, and decline to
# create a core file.
#
# This procedure just answers whatever questions come up until it sees
# a GDB prompt; it doesn't require you to have matched the input up to
# any specific point. However, it only answers questions it sees in
# the output itself, so if you've matched a question, you had better
# answer it yourself before calling this.
#
# The variable `gdb_internal_error_regexp' is set up to match the
# internal error message, but none of the questions that follow it, so
# you can write code like this:
#
# gdb_expect {
# ...
# -re $gdb_internal_error_regexp {
# gdb_internal_error_resync "$message (internal error)"
# }
# ...
# }
proc gdb_internal_error_resync {testname} {
global gdb_prompt
gdb_expect {
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n"
exp_continue
}
-re "Create a core file of GDB\\? \\(y or n\\) $" {
send_gdb "n\n"
exp_continue
}
-re "$gdb_prompt $" {
# We're resynchronized.
}
timeout {
fail "$testname (internal error resync timeout)"
}
}
}
# gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE
# Send a command to gdb; test the result.
@ -445,7 +395,6 @@ proc gdb_test { args } {
global verbose
global gdb_prompt
global GDB
global gdb_internal_error_regexp
upvar timeout timeout
if [llength $args]>2 then {
@ -528,10 +477,6 @@ proc gdb_test { args } {
}
}
gdb_expect $tmt {
-re $gdb_internal_error_regexp {
fail "$message"
gdb_internal_error_resync "$message (internal error)"
}
-re "\\*\\*\\* DOSEXIT code.*" {
if { $message != "" } {
fail "$message";