old-cross-binutils/gdb/testsuite/gdb.hp/gdb.base-hp/callfwmall.exp
Joel Brobecker e22f8b7c8c Switch the license of all .exp files to GPLv3.
Switch the license of all .f and .f90 files to GPLv3.
        Switch the license of all .s and .S files to GPLv3.
2007-08-23 18:14:19 +00:00

343 lines
12 KiB
Text

# Copyright 1997, 1998, 1999, 2007 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/>. */
# Please email any bugs, comments, and/or additions to this file to:
# bug-gdb@prep.ai.mit.edu
# This file was written by Fred Fish. (fnf@cygnus.com)
# These tests are the same as those in callfuncs.exp, except that the
# test program here does not call malloc.
#
# "What in the world does malloc have to do with calling functions in
# the inferior?" Well, nothing. GDB's ability to invoke a function
# in the inferior program works just fine in programs that have no
# malloc function available. It doesn't rely on the inferior's
# malloc, directly or indirectly. It just uses the inferior's stack
# space.
#
# "Then what's the point of this test file?" Well, it just so happens
# that this file, in addition to testing inferior function calls, also
# tests GDB's ability to evaluate string literals (like "string 1" and
# "string 2" in the tests below). Evaluating *those* sorts of
# expressions does require malloc.
#
# (As an extension to C, GDB also has a syntax for literal arrays of
# anything, not just characters. For example, the expression
# {2,3,4,5} (which appears in the tests below) evaluates to an array
# of four ints. So rather than talking just about string literals,
# we'll use the broader term "array literals".)
#
# Now, in this file, we only evaluate array literals when we're about
# to pass them to a function, but don't be confused --- this is a red
# herring. You can evaluate "abcdef" even if you're not about to pass
# that to a function, and doing so requires malloc even if you're just
# going to store a pointer to it in a variable, like this:
#
# (gdb) ptype s
# type = char *
# (gdb) set variable s = "abcdef"
#
# According to C's rules for evaluating expressions, arrays are
# converted into pointers to their first element. This means that, in
# order to evaluate an expression like "abcdef", GDB needs to actually
# find some memory in the inferior we can plop the characters into;
# then we use that memory's address as the address of our array
# literal. GDB finds this memory by calling the inferior's malloc
# function, if it has one. So, evaluating an array literal depends on
# performing an inferior function call, but not vice versa. (GDB
# can't just allocate the space on the stack; the pointer may remain
# live long after the current frame has been popped.)
#
# "But, if evaluating array literals requires malloc, what's the point
# of testing that GDB can do so in a program that doesn't have malloc?
# It can't work!" On most systems, that's right, but HP-UX has some
# sort of dynamic linking magic that ensures that *every* program has
# malloc. So on HP-UX, GDB can evaluate array literals even in
# inferior programs that don't use malloc. That's why this test is in
# gdb.hp.
#
# This file has, for some reason, led to well more than its fair share
# of misunderstandings about the relationship between array literal
# expressions and inferior function calls. Folks talk as if you can
# only evaluate array literals when you're about to pass them to a
# function. I think they're assuming that, since GDB is constructing
# a new frame on the inferior's stack (correct), it's going to use
# that space for the array literals (incorrect). Remember that those
# array literals may need to be live long after the inferior function
# call returns; GDB can't tell.
#
# What makes the confusion worse is that there *is* a relationship
# between array literals and inferior function calls --- GDB uses
# inferior function calls to evaluate array literals. But many people
# jump to other, incorrect conclusions about this.
if $tracelevel then {
strace $tracelevel
}
set prms_id 0
set bug_id 0
if { [skip_hp_tests] } then { continue }
set testfile "callfwmall"
set srcfile ${testfile}.c
set binfile ${objdir}/${subdir}/${testfile}
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
untested callfwmall.exp
return -1
}
# Create and source the file that provides information about the compiler
# used to compile the test case.
if [get_compiler_info ${binfile}] {
return -1;
}
if {$hp_aCC_compiler} {
set prototypes 1
} else {
set prototypes 0
}
# Some targets can't call functions, so don't even bother with this
# test.
if [target_info exists gdb,cannot_call_functions] {
setup_xfail "*-*-*" 2416
fail "This target can not call functions"
continue
}
# Set the current language to C. This counts as a test. If it
# fails, then we skip the other tests.
proc set_lang_c {} {
global gdb_prompt
send_gdb "set language c\n"
gdb_expect {
-re ".*$gdb_prompt $" {}
timeout { fail "set language c (timeout)" ; return 0 }
}
send_gdb "show language\n"
gdb_expect {
-re ".* source language is \"c\".*$gdb_prompt $" {
pass "set language to \"c\""
return 1
}
-re ".*$gdb_prompt $" {
fail "setting language to \"c\""
return 0
}
timeout {
fail "can't show language (timeout)"
return 0
}
}
}
# FIXME: Before calling this proc, we should probably verify that
# we can call inferior functions and get a valid integral value
# returned.
# Note that it is OK to check for 0 or 1 as the returned values, because C
# specifies that the numeric value of a relational or logical expression
# (computed in the inferior) is 1 for true and 0 for false.
proc do_function_calls {} {
global prototypes
global gcc_compiled
global gdb_prompt
# We need to up this because this can be really slow on some boards.
set timeout 60;
gdb_test "p t_char_values(0,0)" " = 0"
gdb_test "p t_char_values('a','b')" " = 1"
gdb_test "p t_char_values(char_val1,char_val2)" " = 1"
gdb_test "p t_char_values('a',char_val2)" " = 1"
gdb_test "p t_char_values(char_val1,'b')" " = 1"
gdb_test "p t_short_values(0,0)" " = 0"
gdb_test "p t_short_values(10,-23)" " = 1"
gdb_test "p t_short_values(short_val1,short_val2)" " = 1"
gdb_test "p t_short_values(10,short_val2)" " = 1"
gdb_test "p t_short_values(short_val1,-23)" " = 1"
gdb_test "p t_int_values(0,0)" " = 0"
gdb_test "p t_int_values(87,-26)" " = 1"
gdb_test "p t_int_values(int_val1,int_val2)" " = 1"
gdb_test "p t_int_values(87,int_val2)" " = 1"
gdb_test "p t_int_values(int_val1,-26)" " = 1"
gdb_test "p t_long_values(0,0)" " = 0"
gdb_test "p t_long_values(789,-321)" " = 1"
gdb_test "p t_long_values(long_val1,long_val2)" " = 1"
gdb_test "p t_long_values(789,long_val2)" " = 1"
gdb_test "p t_long_values(long_val1,-321)" " = 1"
if ![target_info exists gdb,skip_float_tests] {
gdb_test "p t_float_values(0.0,0.0)" " = 0"
# These next four tests fail on the mn10300.
# The first value is passed in regs, the other in memory.
# Gcc emits different stabs for the two parameters; the first is
# claimed to be a float, the second a double.
# dbxout.c in gcc claims this is the desired behavior.
setup_xfail "mn10300-*-*"
gdb_test "p t_float_values(3.14159,-2.3765)" " = 1"
setup_xfail "mn10300-*-*"
gdb_test "p t_float_values(float_val1,float_val2)" " = 1"
setup_xfail "mn10300-*-*"
gdb_test "p t_float_values(3.14159,float_val2)" " = 1"
setup_xfail "mn10300-*-*"
gdb_test "p t_float_values(float_val1,-2.3765)" " = 1"
# Test passing of arguments which might not be widened.
gdb_test "p t_float_values2(0.0,0.0)" " = 0"
# Although PR 5318 mentions SunOS specifically, this seems
# to be a generic problem on quite a few platforms.
if $prototypes then {
setup_xfail "sparc-*-*" "mips*-*-*" 5318
if {!$gcc_compiled} then {
setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318
}
}
gdb_test "p t_float_values2(3.14159,float_val2)" " = 1"
gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55"
gdb_test "p t_double_values(0.0,0.0)" " = 0"
gdb_test "p t_double_values(45.654,-67.66)" " = 1"
gdb_test "p t_double_values(double_val1,double_val2)" " = 1"
gdb_test "p t_double_values(45.654,double_val2)" " = 1"
gdb_test "p t_double_values(double_val1,-67.66)" " = 1"
}
gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
gdb_test "p t_string_values(\"string 1\",\"string 2\")" " = 1"
gdb_test "p t_string_values(\"string 1\",string_val2)" " = 1"
gdb_test "p t_string_values(string_val1,\"string 2\")" " = 1"
gdb_test "p t_char_array_values(char_array_val2,char_array_val1)" " = 0"
gdb_test "p t_char_array_values(char_array_val1,char_array_val2)" " = 1"
gdb_test "p t_char_array_values(\"carray 1\",\"carray 2\")" " = 1"
gdb_test "p t_char_array_values(\"carray 1\",char_array_val2)" " = 1"
gdb_test "p t_char_array_values(char_array_val1,\"carray 2\")" " = 1"
gdb_test "p doubleit(4)" " = 8"
gdb_test "p add(4,5)" " = 9"
gdb_test "p t_func_values(func_val2,func_val1)" " = 0"
gdb_test "p t_func_values(func_val1,func_val2)" " = 1"
# On the rs6000, we need to pass the address of the trampoline routine,
# not the address of add itself. I don't know how to go from add to
# the address of the trampoline. Similar problems exist on the HPPA,
# and in fact can present an unsolvable problem as the stubs may not
# even exist in the user's program. We've slightly recoded t_func_values
# to avoid such problems in the common case. This may or may not help
# the RS6000.
setup_xfail "rs6000*-*-*"
if {![istarget hppa*-*-hpux*]} then {
gdb_test "p t_func_values(add,func_val2)" " = 1"
}
setup_xfail "rs6000*-*-*"
if {![istarget hppa*-*-hpux*]} then {
gdb_test "p t_func_values(func_val1,doubleit)" " = 1"
}
gdb_test "p t_call_add(func_val1,3,4)" " = 7"
setup_xfail "rs6000*-*-*"
if {![istarget hppa*-*-hpux*]} then {
gdb_test "p t_call_add(add,3,4)" " = 7"
}
gdb_test "p t_enum_value1(enumval1)" " = 1"
gdb_test "p t_enum_value1(enum_val1)" " = 1"
gdb_test "p t_enum_value1(enum_val2)" " = 0"
gdb_test "p t_enum_value2(enumval2)" " = 1"
gdb_test "p t_enum_value2(enum_val2)" " = 1"
gdb_test "p t_enum_value2(enum_val1)" " = 0"
gdb_test "p sum_args(1,{2})" " = 2"
gdb_test "p sum_args(2,{2,3})" " = 5"
gdb_test "p sum_args(3,{2,3,4})" " = 9"
gdb_test "p sum_args(4,{2,3,4,5})" " = 14"
gdb_test "p sum10 (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)" " = 55"
gdb_test "p t_structs_c(struct_val1)" "= 120 'x'" \
"call inferior func with struct - returns char"
gdb_test "p t_structs_s(struct_val1)" "= 87" \
"call inferior func with struct - returns short"
gdb_test "p t_structs_i(struct_val1)" "= 76" \
"call inferior func with struct - returns int"
gdb_test "p t_structs_l(struct_val1)" "= 51" \
"call inferior func with struct - returns long"
gdb_test "p t_structs_f(struct_val1)" "= 2.12.*" \
"call inferior func with struct - returns float"
gdb_test "p t_structs_d(struct_val1)" "= 9.87.*" \
"call inferior func with struct - returns double"
gdb_test "p t_structs_a(struct_val1)" "= (.unsigned char .. )?\"foo\"" \
"call inferior func with struct - returns char *"
}
# Start with a fresh gdb.
gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}
gdb_test "set print sevenbit-strings" ""
gdb_test "set print address off" ""
gdb_test "set width 0" ""
if { $hp_aCC_compiler } {
# Do not set language explicitly to 'C'. This will cause aCC
# tests to fail because promotion rules are different. Just let
# the language be set to the default.
if { ![runto_main] } {
gdb_suppress_tests;
}
gdb_test "set overload-resolution 0" ".*"
} else {
if { ![set_lang_c] } {
gdb_suppress_tests;
} else {
if { ![runto_main] } {
gdb_suppress_tests;
}
}
}
gdb_test "next" ".*"
do_function_calls
return 0