]> git.ipfire.org Git - thirdparty/binutils-gdb.git/blame - gdb/testsuite/gdb.hp/gdb.base-hp/callfwmall.exp
Switch the license of all .c files to GPLv3.
[thirdparty/binutils-gdb.git] / gdb / testsuite / gdb.hp / gdb.base-hp / callfwmall.exp
CommitLineData
6aba47ca 1# Copyright 1997, 1998, 1999, 2007 Free Software Foundation, Inc.
daf3f280
JM
2
3# This program is free software; you can redistribute it and/or modify
4# it under the terms of the GNU General Public License as published by
5# the Free Software Foundation; either version 2 of the License, or
6# (at your option) any later version.
7#
8# This program is distributed in the hope that it will be useful,
9# but WITHOUT ANY WARRANTY; without even the implied warranty of
10# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
11# GNU General Public License for more details.
12#
13# You should have received a copy of the GNU General Public License
14# along with this program; if not, write to the Free Software
15# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
16
17# Please email any bugs, comments, and/or additions to this file to:
18# bug-gdb@prep.ai.mit.edu
19
20# This file was written by Fred Fish. (fnf@cygnus.com)
21
37225f62
JB
22# These tests are the same as those in callfuncs.exp, except that the
23# test program here does not call malloc.
24#
25# "What in the world does malloc have to do with calling functions in
26# the inferior?" Well, nothing. GDB's ability to invoke a function
27# in the inferior program works just fine in programs that have no
28# malloc function available. It doesn't rely on the inferior's
29# malloc, directly or indirectly. It just uses the inferior's stack
30# space.
31#
32# "Then what's the point of this test file?" Well, it just so happens
33# that this file, in addition to testing inferior function calls, also
34# tests GDB's ability to evaluate string literals (like "string 1" and
35# "string 2" in the tests below). Evaluating *those* sorts of
36# expressions does require malloc.
37#
38# (As an extension to C, GDB also has a syntax for literal arrays of
39# anything, not just characters. For example, the expression
40# {2,3,4,5} (which appears in the tests below) evaluates to an array
41# of four ints. So rather than talking just about string literals,
42# we'll use the broader term "array literals".)
43#
44# Now, in this file, we only evaluate array literals when we're about
45# to pass them to a function, but don't be confused --- this is a red
46# herring. You can evaluate "abcdef" even if you're not about to pass
47# that to a function, and doing so requires malloc even if you're just
48# going to store a pointer to it in a variable, like this:
49#
50# (gdb) ptype s
51# type = char *
52# (gdb) set variable s = "abcdef"
53#
54# According to C's rules for evaluating expressions, arrays are
55# converted into pointers to their first element. This means that, in
56# order to evaluate an expression like "abcdef", GDB needs to actually
57# find some memory in the inferior we can plop the characters into;
58# then we use that memory's address as the address of our array
59# literal. GDB finds this memory by calling the inferior's malloc
60# function, if it has one. So, evaluating an array literal depends on
61# performing an inferior function call, but not vice versa. (GDB
62# can't just allocate the space on the stack; the pointer may remain
63# live long after the current frame has been popped.)
64#
65# "But, if evaluating array literals requires malloc, what's the point
66# of testing that GDB can do so in a program that doesn't have malloc?
67# It can't work!" On most systems, that's right, but HP-UX has some
68# sort of dynamic linking magic that ensures that *every* program has
69# malloc. So on HP-UX, GDB can evaluate array literals even in
70# inferior programs that don't use malloc. That's why this test is in
71# gdb.hp.
72#
73# This file has, for some reason, led to well more than its fair share
74# of misunderstandings about the relationship between array literal
75# expressions and inferior function calls. Folks talk as if you can
76# only evaluate array literals when you're about to pass them to a
77# function. I think they're assuming that, since GDB is constructing
78# a new frame on the inferior's stack (correct), it's going to use
79# that space for the array literals (incorrect). Remember that those
80# array literals may need to be live long after the inferior function
81# call returns; GDB can't tell.
82#
83# What makes the confusion worse is that there *is* a relationship
84# between array literals and inferior function calls --- GDB uses
85# inferior function calls to evaluate array literals. But many people
86# jump to other, incorrect conclusions about this.
daf3f280
JM
87
88if $tracelevel then {
89 strace $tracelevel
90}
91
92set prms_id 0
93set bug_id 0
94
37225f62
JB
95if { [skip_hp_tests] } then { continue }
96
daf3f280
JM
97set testfile "callfwmall"
98set srcfile ${testfile}.c
99set binfile ${objdir}/${subdir}/${testfile}
100
101if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
b60f0898
JB
102 untested callfwmall.exp
103 return -1
daf3f280
JM
104}
105
106# Create and source the file that provides information about the compiler
107# used to compile the test case.
108
109if [get_compiler_info ${binfile}] {
110 return -1;
111}
112
113if {$hp_aCC_compiler} {
114 set prototypes 1
115} else {
116 set prototypes 0
117}
118
119
9fbfe2dc
AC
120# Some targets can't call functions, so don't even bother with this
121# test.
daf3f280
JM
122if [target_info exists gdb,cannot_call_functions] {
123 setup_xfail "*-*-*" 2416
124 fail "This target can not call functions"
125 continue
126}
127
128# Set the current language to C. This counts as a test. If it
129# fails, then we skip the other tests.
130
131proc set_lang_c {} {
132 global gdb_prompt
133
134 send_gdb "set language c\n"
135 gdb_expect {
136 -re ".*$gdb_prompt $" {}
137 timeout { fail "set language c (timeout)" ; return 0 }
138 }
139
140 send_gdb "show language\n"
141 gdb_expect {
142 -re ".* source language is \"c\".*$gdb_prompt $" {
143 pass "set language to \"c\""
144 return 1
145 }
146 -re ".*$gdb_prompt $" {
147 fail "setting language to \"c\""
148 return 0
149 }
150 timeout {
151 fail "can't show language (timeout)"
152 return 0
153 }
154 }
155}
156
157# FIXME: Before calling this proc, we should probably verify that
158# we can call inferior functions and get a valid integral value
159# returned.
160# Note that it is OK to check for 0 or 1 as the returned values, because C
161# specifies that the numeric value of a relational or logical expression
162# (computed in the inferior) is 1 for true and 0 for false.
163
164proc do_function_calls {} {
165 global prototypes
166 global gcc_compiled
a0b3c4fd
JM
167 global gdb_prompt
168
daf3f280
JM
169 # We need to up this because this can be really slow on some boards.
170 set timeout 60;
171
172 gdb_test "p t_char_values(0,0)" " = 0"
173 gdb_test "p t_char_values('a','b')" " = 1"
174 gdb_test "p t_char_values(char_val1,char_val2)" " = 1"
175 gdb_test "p t_char_values('a',char_val2)" " = 1"
176 gdb_test "p t_char_values(char_val1,'b')" " = 1"
177
178 gdb_test "p t_short_values(0,0)" " = 0"
179 gdb_test "p t_short_values(10,-23)" " = 1"
180 gdb_test "p t_short_values(short_val1,short_val2)" " = 1"
181 gdb_test "p t_short_values(10,short_val2)" " = 1"
182 gdb_test "p t_short_values(short_val1,-23)" " = 1"
183
184 gdb_test "p t_int_values(0,0)" " = 0"
185 gdb_test "p t_int_values(87,-26)" " = 1"
186 gdb_test "p t_int_values(int_val1,int_val2)" " = 1"
187 gdb_test "p t_int_values(87,int_val2)" " = 1"
188 gdb_test "p t_int_values(int_val1,-26)" " = 1"
189
190 gdb_test "p t_long_values(0,0)" " = 0"
191 gdb_test "p t_long_values(789,-321)" " = 1"
192 gdb_test "p t_long_values(long_val1,long_val2)" " = 1"
193 gdb_test "p t_long_values(789,long_val2)" " = 1"
194 gdb_test "p t_long_values(long_val1,-321)" " = 1"
195
196 if ![target_info exists gdb,skip_float_tests] {
197 gdb_test "p t_float_values(0.0,0.0)" " = 0"
198
199 # These next four tests fail on the mn10300.
200 # The first value is passed in regs, the other in memory.
201 # Gcc emits different stabs for the two parameters; the first is
202 # claimed to be a float, the second a double.
203 # dbxout.c in gcc claims this is the desired behavior.
a0b3c4fd 204 setup_xfail "mn10300-*-*"
daf3f280 205 gdb_test "p t_float_values(3.14159,-2.3765)" " = 1"
a0b3c4fd 206 setup_xfail "mn10300-*-*"
daf3f280 207 gdb_test "p t_float_values(float_val1,float_val2)" " = 1"
a0b3c4fd 208 setup_xfail "mn10300-*-*"
daf3f280 209 gdb_test "p t_float_values(3.14159,float_val2)" " = 1"
a0b3c4fd 210 setup_xfail "mn10300-*-*"
daf3f280
JM
211 gdb_test "p t_float_values(float_val1,-2.3765)" " = 1"
212
213 # Test passing of arguments which might not be widened.
214 gdb_test "p t_float_values2(0.0,0.0)" " = 0"
215
216 # Although PR 5318 mentions SunOS specifically, this seems
217 # to be a generic problem on quite a few platforms.
218 if $prototypes then {
219 setup_xfail "sparc-*-*" "mips*-*-*" 5318
220 if {!$gcc_compiled} then {
221 setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318
222 }
223 }
224 gdb_test "p t_float_values2(3.14159,float_val2)" " = 1"
225 gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55"
226
227 gdb_test "p t_double_values(0.0,0.0)" " = 0"
228 gdb_test "p t_double_values(45.654,-67.66)" " = 1"
229 gdb_test "p t_double_values(double_val1,double_val2)" " = 1"
230 gdb_test "p t_double_values(45.654,double_val2)" " = 1"
231 gdb_test "p t_double_values(double_val1,-67.66)" " = 1"
232
233 }
234
235 gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
236 gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
237 gdb_test "p t_string_values(\"string 1\",\"string 2\")" " = 1"
238 gdb_test "p t_string_values(\"string 1\",string_val2)" " = 1"
239 gdb_test "p t_string_values(string_val1,\"string 2\")" " = 1"
240
241 gdb_test "p t_char_array_values(char_array_val2,char_array_val1)" " = 0"
242 gdb_test "p t_char_array_values(char_array_val1,char_array_val2)" " = 1"
243 gdb_test "p t_char_array_values(\"carray 1\",\"carray 2\")" " = 1"
244 gdb_test "p t_char_array_values(\"carray 1\",char_array_val2)" " = 1"
245 gdb_test "p t_char_array_values(char_array_val1,\"carray 2\")" " = 1"
246
247 gdb_test "p doubleit(4)" " = 8"
248 gdb_test "p add(4,5)" " = 9"
249 gdb_test "p t_func_values(func_val2,func_val1)" " = 0"
250 gdb_test "p t_func_values(func_val1,func_val2)" " = 1"
251
252 # On the rs6000, we need to pass the address of the trampoline routine,
253 # not the address of add itself. I don't know how to go from add to
254 # the address of the trampoline. Similar problems exist on the HPPA,
255 # and in fact can present an unsolvable problem as the stubs may not
256 # even exist in the user's program. We've slightly recoded t_func_values
257 # to avoid such problems in the common case. This may or may not help
258 # the RS6000.
259 setup_xfail "rs6000*-*-*"
daf3f280 260
a0b3c4fd 261 if {![istarget hppa*-*-hpux*]} then {
daf3f280
JM
262 gdb_test "p t_func_values(add,func_val2)" " = 1"
263 }
264
265 setup_xfail "rs6000*-*-*"
daf3f280 266
a0b3c4fd 267 if {![istarget hppa*-*-hpux*]} then {
daf3f280
JM
268 gdb_test "p t_func_values(func_val1,doubleit)" " = 1"
269 }
270
271 gdb_test "p t_call_add(func_val1,3,4)" " = 7"
272
273 setup_xfail "rs6000*-*-*"
daf3f280 274
a0b3c4fd 275 if {![istarget hppa*-*-hpux*]} then {
daf3f280
JM
276 gdb_test "p t_call_add(add,3,4)" " = 7"
277 }
278
279 gdb_test "p t_enum_value1(enumval1)" " = 1"
280 gdb_test "p t_enum_value1(enum_val1)" " = 1"
281 gdb_test "p t_enum_value1(enum_val2)" " = 0"
282
283 gdb_test "p t_enum_value2(enumval2)" " = 1"
284 gdb_test "p t_enum_value2(enum_val2)" " = 1"
285 gdb_test "p t_enum_value2(enum_val1)" " = 0"
286
287 gdb_test "p sum_args(1,{2})" " = 2"
288 gdb_test "p sum_args(2,{2,3})" " = 5"
289 gdb_test "p sum_args(3,{2,3,4})" " = 9"
290 gdb_test "p sum_args(4,{2,3,4,5})" " = 14"
291 gdb_test "p sum10 (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)" " = 55"
292
293 gdb_test "p t_structs_c(struct_val1)" "= 120 'x'" \
294 "call inferior func with struct - returns char"
295 gdb_test "p t_structs_s(struct_val1)" "= 87" \
296 "call inferior func with struct - returns short"
297 gdb_test "p t_structs_i(struct_val1)" "= 76" \
298 "call inferior func with struct - returns int"
299 gdb_test "p t_structs_l(struct_val1)" "= 51" \
300 "call inferior func with struct - returns long"
daf3f280
JM
301 gdb_test "p t_structs_f(struct_val1)" "= 2.12.*" \
302 "call inferior func with struct - returns float"
daf3f280
JM
303 gdb_test "p t_structs_d(struct_val1)" "= 9.87.*" \
304 "call inferior func with struct - returns double"
305 gdb_test "p t_structs_a(struct_val1)" "= (.unsigned char .. )?\"foo\"" \
306 "call inferior func with struct - returns char *"
307
308}
309
310# Start with a fresh gdb.
311
312gdb_exit
313gdb_start
314gdb_reinitialize_dir $srcdir/$subdir
315gdb_load ${binfile}
316
317gdb_test "set print sevenbit-strings" ""
318gdb_test "set print address off" ""
319gdb_test "set width 0" ""
320
321if { $hp_aCC_compiler } {
322 # Do not set language explicitly to 'C'. This will cause aCC
323 # tests to fail because promotion rules are different. Just let
324 # the language be set to the default.
325
326 if { ![runto_main] } {
327 gdb_suppress_tests;
328 }
329
330 gdb_test "set overload-resolution 0" ".*"
331} else {
332 if { ![set_lang_c] } {
333 gdb_suppress_tests;
334 } else {
335 if { ![runto_main] } {
336 gdb_suppress_tests;
337 }
338 }
339}
340
341gdb_test "next" ".*"
342do_function_calls
343
344return 0