OSDN Git Service

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