daily update

[thirdparty/binutils-gdb.git] / gdb / testsuite / gdb.base / step-test.exp

# Copyright 1997, 1998, 1999, 2000, 2002 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

# Please email any bugs, comments, and/or additions to this file to:
# bug-gdb@prep.ai.mit.edu

# use this to debug:
#
#log_user 1

# step-test.exp -- Expect script to test stepping in gdb

if $tracelevel then {
    strace $tracelevel
}

set testfile step-test
set srcfile ${srcdir}/${subdir}/${testfile}.c
set binfile ${objdir}/${subdir}/${testfile}

remote_exec build "rm -f ${binfile}"
if { [gdb_compile "${srcfile}" "${binfile}" executable {debug}] != "" } {
     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
}

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

if ![runto_main] then {
   fail "Can't run to main"
   return 0
}

# Set a breakpoint at line 45, if stepi then finish fails, we would
# run to the end of the program, which would mess up the rest of the tests.
  
# Vanilla step/next
#
gdb_test "next" ".*${decimal}.*x = 1;.*" "next 1"
gdb_test "step" ".*${decimal}.*y = 2;.*" "step 1"

# With count
#
gdb_test "next 2" ".*${decimal}.*w = w.*2;.*" "next 2"
gdb_test "step 3" ".*${decimal}.*z = z.*5;.*" "step 3"
gdb_test "next" ".*${decimal}.*callee.*OVER.*" "next 3"

# Step over call
#
gdb_test "next" ".*${decimal}.*callee.*INTO.*" "next over"

# Step into call
#
gdb_test "step" ".*${decimal}.*myglob.*"   "step into"

# Step out of call
#
# I wonder if this is really portable.  Are there any caller-saves
# platforms, on which `finish' will return you to some kind of pop
# instruction, which is attributed to the line containing the function
# call?

# On PA64, we end up at a different instruction than PA32.
# On IA-64, we also end up on callee instead of on the next line due
# to the restoration of the global pointer (which is a caller-save).
if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"]} {
    send_gdb "finish\n"
    gdb_expect {
        -re ".*${decimal}.*a.*5.*= a.*3.*$gdb_prompt $" { pass "step out 1" }
        -re ".*${decimal}.*callee.*INTO.*$gdb_prompt $" { pass "step out 2" }
        timeout { fail "step out" }
    }
} else {
    gdb_test "finish" ".*${decimal}.*a.*5.*= a.*3.*" "step out"
}

### Testing nexti and stepi.
###
### test_i NAME COMMAND HERE THERE
###
### Send COMMAND to gdb over and over, while the output matches the
### regexp HERE, followed by the gdb prompt.  Pass if the output
### eventually matches the regexp THERE, followed by the gdb prompt;
### fail if we have to iterate more than a hundred times, we time out
### talking to gdb, or we get output which is neither HERE nor THERE.  :)
###
### Use NAME as the name of the test.
###
### The exact regexps used are "$HERE.*$gdb_prompt $"
###                        and "$THERE.*$gdb_prompt $"
### 
proc test_i {name command here there} {
    global gdb_prompt
    
    set i 0
    while 1 {
	send_gdb "${command}\n"
	gdb_expect {
	    -re "$here.*$gdb_prompt $" {
		# Okay, we're still on the same line.  Just step again.
	    }
	    -re "$there.*$gdb_prompt $" {
		# We've reached the next line.  Rah.
		pass "$name"
		return
	    }
	    -re "$gdb_prompt $" {
		# We got something else.  Fail.
		fail "$name"
		return
	    }
	    timeout {
		fail "$name (timeout)"
		return
	    }
	}

	# Have we gone for too many steps without seeing any progress?
	if {[incr i] >= 100} {
	    fail "$name (no progress after 100 steps)"
	    return
	}
    }
}

test_i "stepi to next line" "stepi" \
       ".*${decimal}.*a.*5.* = a.*3" \
       ".*${decimal}.*callee.*STEPI"
test_i "stepi into function" "stepi" \
       ".*${decimal}.*callee.*STEPI" \
       ".*callee \\(\\) at .*step-test\\.c" 

# Continue to step until we reach the function's body.  This makes it
# more likely that we've actually completed the prologue, so "finish"
# will work.
test_i "stepi into function's first source line" "stepi" \
	".*${decimal}.*int callee" \
	".*${decimal}.*myglob.*; return 0;"

# Have to be careful here, if the finish does not work, 
# then we may run to the end of the program, which
# will cause erroneous failures in the rest of the tests
send_gdb "finish\n"
gdb_expect {
  -re ".*(Program received|Program exited).*$gdb_prompt $" {
    # Oops... We ran to the end of the program...  Better reset     
    if {![runto_main]} then {
      fail "Can't run to main"
      return 0
    }
    if {![runto step-test.c:45]} {
      fail "Can't run to line 45"
      return 0
    }
    fail "stepi: finish call"
  }
  -re ".*${decimal}.*callee.*NEXTI.*$gdb_prompt $" {
    pass "stepi: finish call"
  }
  -re ".*${decimal}.*callee.*STEPI.*$gdb_prompt $" {
    # On PA64, we end up at a different instruction than PA32.
    # On IA-64, we end up on callee instead of on the following line due
    # to the restoration of the global pointer.
    if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"] } {
        pass "stepi: finish call 2"
    } else {
	fail "stepi: finish call 2"
        return
    }
  }
  -re "$gdb_prompt $" {
    # We got something else.  Fail.
    fail "stepi: finish call"
    return
  }
  timeout {
    fail "stepi: finish call (timeout)"
    return
  }
}

test_i "nexti over function" "nexti" \
       ".*${decimal}.*callee.*NEXTI" \
       ".*${decimal}.*y = w \\+ z;"

# On some platforms, if we try to step into a function call that
# passes a large structure by value, then we actually end up stepping
# into memcpy, bcopy, or some such --- GCC emits the call to pass the
# argument.  Opinion is bitterly divided about whether this is the
# right behavior for GDB or not, but we'll catch it here, so folks
# won't forget about it.

gdb_test \
  "break [gdb_get_line_number "step-test.exp: large struct by value"]" \
  ".*Breakpoint.* at .*" \
  "set breakpoint at call to large_struct_by_value"
gdb_test "continue" \
         ".*Breakpoint ${decimal},.*large_struct_by_value.*" \
	 "run to pass large struct"
send_gdb "step\n"
gdb_expect {
    -re ".*step-test.exp: arrive here 1.*$gdb_prompt $" {
	pass "large struct by value"
    }
    -re ".*(memcpy|bcopy).*$gdb_prompt $" {
	send_gdb "finish\n" ; gdb_expect -re "$gdb_prompt $"
	send_gdb "step\n"
	exp_continue
    }
    -re ".*$gdb_prompt $" {
	fail "large struct by value"
    }
    timeout {
	fail "large struct by value (timeout)"
    }
}

gdb_continue_to_end "step-test.exp"

return 0