gdb/fortran: Handle internal function calls

If an convenience function is defined in python (or guile), then
currently this will not work in Fortran, instead the user is given
this message:

  (gdb) set language fortran
  (gdb) p $myfunc (3)
  Cannot perform substring on this type

Compare this to C:

  (gdb) set language c
  (gdb) p $myfunc (3)
  $1 = 1

After this patch we see the same behaviour in both C and Fortran.
I've extended the test to check that all languages can call the
convenience functions - only Fortran was broken.

When calling convenience functions in Fortran we don't need to perform
the same value preparation (passing by pointer) that we would for
calling a native function - passing the real value is fine.

gdb/ChangeLog:

	* eval.c (evaluate_subexp_standard): Handle internal functions
	during Fortran function call handling.

gdb/testsuite/ChangeLog:

	* gdb.python/py-function.exp: Check calling helper function from
	all languages.
	* lib/gdb.exp (gdb_supported_languages): New proc.

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 35a9550ecdd440f9f6cd5161c82628306b2aed4e..aee0d967e1d1b28db13a694607a9be5fe4673038 100644 (file)
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2019-04-01  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+       * eval.c (evaluate_subexp_standard): Handle internal functions
+       during Fortran function call handling.
+
 2019-04-01  Andrew Burgess  <andrew.burgess@embecosm.com>
 
        * NEWS: Mention new internal functions.

diff --git a/gdb/eval.c b/gdb/eval.c
index 9d8eb3476baf226b5ae2d3389c2bb39872933f8c..3f768b45309c7aba119580bb56cbd5d9e569a5a1 100644 (file)
--- a/gdb/eval.c
+++ b/gdb/eval.c
@@ -1979,6 +1979,7 @@ evaluate_subexp_standard (struct type *expect_type,
 
        case TYPE_CODE_PTR:
        case TYPE_CODE_FUNC:
+       case TYPE_CODE_INTERNAL_FUNCTION:
          /* It's a function call.  */
          /* Allocate arg vector, including space for the function to be
             called in argvec[0] and a terminating NULL.  */
@@ -1996,10 +1997,13 @@ evaluate_subexp_standard (struct type *expect_type,
                 results in malloc being called with a pointer to an integer
                 followed by an attempt to malloc the arguments to malloc in
                 target memory.  Infinite recursion ensues.  */
-             bool is_artificial =
-               TYPE_FIELD_ARTIFICIAL (value_type (arg1), tem - 1);
-             argvec[tem] = fortran_argument_convert (argvec[tem],
-                                                     is_artificial);
+             if (code == TYPE_CODE_PTR || code == TYPE_CODE_FUNC)
+               {
+                 bool is_artificial
+                   = TYPE_FIELD_ARTIFICIAL (value_type (arg1), tem - 1);
+                 argvec[tem] = fortran_argument_convert (argvec[tem],
+                                                         is_artificial);
+               }
            }
          argvec[tem] = 0;      /* signal end of arglist */
          if (noside == EVAL_SKIP)

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 7d603ad6c1c975da4d9a77053cc13b8b924e1386..45c5eb1762bd440f2265d41ca047a369f1b18a31 100644 (file)
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2019-04-01  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+       * gdb.python/py-function.exp: Check calling helper function from
+       all languages.
+       * lib/gdb.exp (gdb_supported_languages): New proc.
+
 2019-04-01  Andrew Burgess  <andrew.burgess@embecosm.com>
 
        * gdb.base/complex-parts.c: New file.

diff --git a/gdb/testsuite/gdb.python/py-function.exp b/gdb/testsuite/gdb.python/py-function.exp
index 76cc57d81c97700646a0f87fa5fa505a9ff52063..01c326b5d0b9b545b01d8a383d876d63aa2e2567 100644 (file)
--- a/gdb/testsuite/gdb.python/py-function.exp
+++ b/gdb/testsuite/gdb.python/py-function.exp
@@ -51,7 +51,13 @@ gdb_py_test_multiple "input value-returning convenience function" \
   "Double ()" "" \
   "end" ""
 
-gdb_test "print \$double (1)" "= 2" "call value-returning function"
+# Different languages can have different parsers, so lets check that
+# internal functions are understood by every language.  Place auto
+# last in the list so we end up back in 'auto' language mode.
+foreach lang [concat [gdb_supported_languages] auto] {
+    gdb_test_no_output "set language $lang"
+    gdb_test "print \$double (1)" "= 2" "call value-returning function, language = $lang"
+}
 
 gdb_py_test_multiple "input int-returning function" \
   "python" "" \

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index e3c6b2d6f5e5f6fe0e22ecd0d54b4dc22b22bacf..1176fdded14c74abb23f5b505c26b972cd4890c4 100644 (file)
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -6353,5 +6353,13 @@ proc cd { dir } {
     builtin_cd $dir
 }
 
+# Return a list of all languages supported by GDB, suitable for use in
+# 'set language NAME'.  This doesn't include either the 'local' or
+# 'auto' keywords.
+proc gdb_supported_languages {} {
+    return [list c objective-c c++ d go fortran modula-2 asm pascal \
+               opencl rust minimal ada]
+}
+
 # Always load compatibility stuff.
 load_lib future.exp