1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
# This testcase is part of GDB, the GNU debugger.
# Copyright 1997-2000, 2002, 2001, 2003-2004, 2007-2012 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 3 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, see <http://www.gnu.org/licenses/>. */
# step-test.exp -- Expect script to test stepping in gdb
set testfile step-test
set srcfile ${testfile}.c
set binfile ${objdir}/${subdir}/${testfile}
remote_exec build "rm -f ${binfile}"
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
untested step-test.exp
return -1
}
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).
# Similarly on MIPS PIC targets.
set test "step out"
if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"] || [istarget "mips*-*-*"]} {
gdb_test_multiple "finish" "$test" {
-re ".*${decimal}.*a.*5.*= a.*3.*$gdb_prompt $" {
pass "$test"
}
-re ".*${decimal}.*callee.*INTO.*$gdb_prompt $" {
pass "$test"
}
}
} 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
gdb_test_multiple "$command" "$name" {
-re "$here.*$gdb_prompt $" {
# Have we gone for too many steps without seeing any progress?
if {[incr i] >= 100} {
fail "$name (no progress after 100 steps)"
return
}
send_gdb "$command\n"
exp_continue
}
-re "$there.*$gdb_prompt $" {
# We've reached the next line. Rah.
pass "$name"
return
}
}
}
test_i "stepi to next line" "stepi" \
".*${decimal}.*a.*5.* = a.*3" \
".*${decimal}.*callee.*STEPI"
# Continue to step until we enter the function. Also keep stepping
# if this passes through a (useless) PLT entry.
test_i "stepi into function" "stepi" \
"(.*${decimal}.*callee.*STEPI|.* in callee@plt)" \
".*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
set test "stepi: finish call"
gdb_test_multiple "finish" "$test" {
-re ".*${decimal}.*callee.*NEXTI.*$gdb_prompt $" {
pass "$test"
}
-re ".*(Program received|$inferior_exited_re).*$gdb_prompt $" {
# Oops... We ran to the end of the program... Better reset
if {![runto_main]} then {
fail "$test (Can't run to main)"
return 0
}
if {![runto step-test.c:45]} {
fail "$test (Can't run to line 45)"
return 0
}
fail "$test"
}
-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.
# Similarly on MIPS PIC targets.
if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"] || [istarget "mips*-*-*"] } {
test_i "$test" "stepi" \
".*${decimal}.*callee.*STEPI" ".*${decimal}.*callee.*NEXTI"
} else {
fail "$test"
}
}
}
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.
# Update 4/4/2002 - Regardless of which opinion you have, you would
# probably have to agree that gdb is currently behaving as designed,
# in the absence of additional code to not stop in functions used
# internally by the compiler. Since the testsuite should be checking
# for conformance to the design, the correct behavior is to accept the
# cases where gdb stops in memcpy/bcopy.
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"
set test "large struct by value"
gdb_test_multiple "step" "$test" {
-re ".*step-test.exp: arrive here 1.*$gdb_prompt $" {
pass "$test"
}
-re ".*(memcpy|bcopy).*$gdb_prompt $" {
send_gdb "finish\n" ; gdb_expect -re "$gdb_prompt $"
send_gdb "step\n"
exp_continue
}
}
gdb_continue_to_end "step-test.exp"
return 0
|
