Subversion Repositories or1k

# Copyright 1997, 1998, 1999 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 2 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, write to the Free Software

# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

# 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}] != "" } {

     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."

}

# 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*-*-*"

    setup_xfail "powerpc*-*-*"

    if {![istarget hppa*-*-hpux*]} then {

        gdb_test "p t_func_values(add,func_val2)" " = 1"

    }

    setup_xfail "rs6000*-*-*"

    setup_xfail "powerpc*-*-*"

    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*-*-*"

    setup_xfail "powerpc*-*-*"

    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