1# Copyright 1997, 1998, 1999 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 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 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. 87 88if $tracelevel then { 89 strace $tracelevel 90} 91 92set prms_id 0 93set bug_id 0 94 95if { [skip_hp_tests] } then { continue } 96 97set testfile "callfwmall" 98set srcfile ${testfile}.c 99set binfile ${objdir}/${subdir}/${testfile} 100 101if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } { 102 gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." 103} 104 105# Create and source the file that provides information about the compiler 106# used to compile the test case. 107 108if [get_compiler_info ${binfile}] { 109 return -1; 110} 111 112if {$hp_aCC_compiler} { 113 set prototypes 1 114} else { 115 set prototypes 0 116} 117 118 119# Some targets can't call functions, so don't even bother with this 120# test. 121if [target_info exists gdb,cannot_call_functions] { 122 setup_xfail "*-*-*" 2416 123 fail "This target can not call functions" 124 continue 125} 126 127# Set the current language to C. This counts as a test. If it 128# fails, then we skip the other tests. 129 130proc set_lang_c {} { 131 global gdb_prompt 132 133 send_gdb "set language c\n" 134 gdb_expect { 135 -re ".*$gdb_prompt $" {} 136 timeout { fail "set language c (timeout)" ; return 0 } 137 } 138 139 send_gdb "show language\n" 140 gdb_expect { 141 -re ".* source language is \"c\".*$gdb_prompt $" { 142 pass "set language to \"c\"" 143 return 1 144 } 145 -re ".*$gdb_prompt $" { 146 fail "setting language to \"c\"" 147 return 0 148 } 149 timeout { 150 fail "can't show language (timeout)" 151 return 0 152 } 153 } 154} 155 156# FIXME: Before calling this proc, we should probably verify that 157# we can call inferior functions and get a valid integral value 158# returned. 159# Note that it is OK to check for 0 or 1 as the returned values, because C 160# specifies that the numeric value of a relational or logical expression 161# (computed in the inferior) is 1 for true and 0 for false. 162 163proc do_function_calls {} { 164 global prototypes 165 global gcc_compiled 166 global gdb_prompt 167 168 # We need to up this because this can be really slow on some boards. 169 set timeout 60; 170 171 gdb_test "p t_char_values(0,0)" " = 0" 172 gdb_test "p t_char_values('a','b')" " = 1" 173 gdb_test "p t_char_values(char_val1,char_val2)" " = 1" 174 gdb_test "p t_char_values('a',char_val2)" " = 1" 175 gdb_test "p t_char_values(char_val1,'b')" " = 1" 176 177 gdb_test "p t_short_values(0,0)" " = 0" 178 gdb_test "p t_short_values(10,-23)" " = 1" 179 gdb_test "p t_short_values(short_val1,short_val2)" " = 1" 180 gdb_test "p t_short_values(10,short_val2)" " = 1" 181 gdb_test "p t_short_values(short_val1,-23)" " = 1" 182 183 gdb_test "p t_int_values(0,0)" " = 0" 184 gdb_test "p t_int_values(87,-26)" " = 1" 185 gdb_test "p t_int_values(int_val1,int_val2)" " = 1" 186 gdb_test "p t_int_values(87,int_val2)" " = 1" 187 gdb_test "p t_int_values(int_val1,-26)" " = 1" 188 189 gdb_test "p t_long_values(0,0)" " = 0" 190 gdb_test "p t_long_values(789,-321)" " = 1" 191 gdb_test "p t_long_values(long_val1,long_val2)" " = 1" 192 gdb_test "p t_long_values(789,long_val2)" " = 1" 193 gdb_test "p t_long_values(long_val1,-321)" " = 1" 194 195 if ![target_info exists gdb,skip_float_tests] { 196 gdb_test "p t_float_values(0.0,0.0)" " = 0" 197 198 # These next four tests fail on the mn10300. 199 # The first value is passed in regs, the other in memory. 200 # Gcc emits different stabs for the two parameters; the first is 201 # claimed to be a float, the second a double. 202 # dbxout.c in gcc claims this is the desired behavior. 203 setup_xfail "mn10300-*-*" 204 gdb_test "p t_float_values(3.14159,-2.3765)" " = 1" 205 setup_xfail "mn10300-*-*" 206 gdb_test "p t_float_values(float_val1,float_val2)" " = 1" 207 setup_xfail "mn10300-*-*" 208 gdb_test "p t_float_values(3.14159,float_val2)" " = 1" 209 setup_xfail "mn10300-*-*" 210 gdb_test "p t_float_values(float_val1,-2.3765)" " = 1" 211 212 # Test passing of arguments which might not be widened. 213 gdb_test "p t_float_values2(0.0,0.0)" " = 0" 214 215 # Although PR 5318 mentions SunOS specifically, this seems 216 # to be a generic problem on quite a few platforms. 217 if $prototypes then { 218 setup_xfail "sparc-*-*" "mips*-*-*" 5318 219 if {!$gcc_compiled} then { 220 setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318 221 } 222 } 223 gdb_test "p t_float_values2(3.14159,float_val2)" " = 1" 224 gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55" 225 226 gdb_test "p t_double_values(0.0,0.0)" " = 0" 227 gdb_test "p t_double_values(45.654,-67.66)" " = 1" 228 gdb_test "p t_double_values(double_val1,double_val2)" " = 1" 229 gdb_test "p t_double_values(45.654,double_val2)" " = 1" 230 gdb_test "p t_double_values(double_val1,-67.66)" " = 1" 231 232 } 233 234 gdb_test "p t_string_values(string_val2,string_val1)" " = 0" 235 gdb_test "p t_string_values(string_val1,string_val2)" " = 1" 236 gdb_test "p t_string_values(\"string 1\",\"string 2\")" " = 1" 237 gdb_test "p t_string_values(\"string 1\",string_val2)" " = 1" 238 gdb_test "p t_string_values(string_val1,\"string 2\")" " = 1" 239 240 gdb_test "p t_char_array_values(char_array_val2,char_array_val1)" " = 0" 241 gdb_test "p t_char_array_values(char_array_val1,char_array_val2)" " = 1" 242 gdb_test "p t_char_array_values(\"carray 1\",\"carray 2\")" " = 1" 243 gdb_test "p t_char_array_values(\"carray 1\",char_array_val2)" " = 1" 244 gdb_test "p t_char_array_values(char_array_val1,\"carray 2\")" " = 1" 245 246 gdb_test "p doubleit(4)" " = 8" 247 gdb_test "p add(4,5)" " = 9" 248 gdb_test "p t_func_values(func_val2,func_val1)" " = 0" 249 gdb_test "p t_func_values(func_val1,func_val2)" " = 1" 250 251 # On the rs6000, we need to pass the address of the trampoline routine, 252 # not the address of add itself. I don't know how to go from add to 253 # the address of the trampoline. Similar problems exist on the HPPA, 254 # and in fact can present an unsolvable problem as the stubs may not 255 # even exist in the user's program. We've slightly recoded t_func_values 256 # to avoid such problems in the common case. This may or may not help 257 # the RS6000. 258 setup_xfail "rs6000*-*-*" 259 setup_xfail "powerpc*-*-*" 260 261 if {![istarget hppa*-*-hpux*]} then { 262 gdb_test "p t_func_values(add,func_val2)" " = 1" 263 } 264 265 setup_xfail "rs6000*-*-*" 266 setup_xfail "powerpc*-*-*" 267 268 if {![istarget hppa*-*-hpux*]} then { 269 gdb_test "p t_func_values(func_val1,doubleit)" " = 1" 270 } 271 272 gdb_test "p t_call_add(func_val1,3,4)" " = 7" 273 274 setup_xfail "rs6000*-*-*" 275 setup_xfail "powerpc*-*-*" 276 277 if {![istarget hppa*-*-hpux*]} then { 278 gdb_test "p t_call_add(add,3,4)" " = 7" 279 } 280 281 gdb_test "p t_enum_value1(enumval1)" " = 1" 282 gdb_test "p t_enum_value1(enum_val1)" " = 1" 283 gdb_test "p t_enum_value1(enum_val2)" " = 0" 284 285 gdb_test "p t_enum_value2(enumval2)" " = 1" 286 gdb_test "p t_enum_value2(enum_val2)" " = 1" 287 gdb_test "p t_enum_value2(enum_val1)" " = 0" 288 289 gdb_test "p sum_args(1,{2})" " = 2" 290 gdb_test "p sum_args(2,{2,3})" " = 5" 291 gdb_test "p sum_args(3,{2,3,4})" " = 9" 292 gdb_test "p sum_args(4,{2,3,4,5})" " = 14" 293 gdb_test "p sum10 (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)" " = 55" 294 295 gdb_test "p t_structs_c(struct_val1)" "= 120 'x'" \ 296 "call inferior func with struct - returns char" 297 gdb_test "p t_structs_s(struct_val1)" "= 87" \ 298 "call inferior func with struct - returns short" 299 gdb_test "p t_structs_i(struct_val1)" "= 76" \ 300 "call inferior func with struct - returns int" 301 gdb_test "p t_structs_l(struct_val1)" "= 51" \ 302 "call inferior func with struct - returns long" 303 gdb_test "p t_structs_f(struct_val1)" "= 2.12.*" \ 304 "call inferior func with struct - returns float" 305 gdb_test "p t_structs_d(struct_val1)" "= 9.87.*" \ 306 "call inferior func with struct - returns double" 307 gdb_test "p t_structs_a(struct_val1)" "= (.unsigned char .. )?\"foo\"" \ 308 "call inferior func with struct - returns char *" 309 310} 311 312# Start with a fresh gdb. 313 314gdb_exit 315gdb_start 316gdb_reinitialize_dir $srcdir/$subdir 317gdb_load ${binfile} 318 319gdb_test "set print sevenbit-strings" "" 320gdb_test "set print address off" "" 321gdb_test "set width 0" "" 322 323if { $hp_aCC_compiler } { 324 # Do not set language explicitly to 'C'. This will cause aCC 325 # tests to fail because promotion rules are different. Just let 326 # the language be set to the default. 327 328 if { ![runto_main] } { 329 gdb_suppress_tests; 330 } 331 332 gdb_test "set overload-resolution 0" ".*" 333} else { 334 if { ![set_lang_c] } { 335 gdb_suppress_tests; 336 } else { 337 if { ![runto_main] } { 338 gdb_suppress_tests; 339 } 340 } 341} 342 343gdb_test "next" ".*" 344do_function_calls 345 346return 0 347