aboutsummaryrefslogtreecommitdiff
path: root/bfd
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2019-02-14 15:49:39 +0000
committerAndrew Burgess <andrew.burgess@embecosm.com>2019-04-01 21:41:51 +0100
commitd7df654955c2423190b05b2507caf624ce3d65bc (patch)
treefabbf61ca39144ed03690e66c239837e7e42d41f /bfd
parent8bdc16587e26100282094c8eaa8e83180ba57afd (diff)
downloadgdb-d7df654955c2423190b05b2507caf624ce3d65bc.zip
gdb-d7df654955c2423190b05b2507caf624ce3d65bc.tar.gz
gdb-d7df654955c2423190b05b2507caf624ce3d65bc.tar.bz2
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.
Diffstat (limited to 'bfd')
0 files changed, 0 insertions, 0 deletions