diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-02-14 15:49:39 +0000 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-04-01 21:41:51 +0100 |
commit | d7df654955c2423190b05b2507caf624ce3d65bc (patch) | |
tree | fabbf61ca39144ed03690e66c239837e7e42d41f /zlib/configure.ac | |
parent | 8bdc16587e26100282094c8eaa8e83180ba57afd (diff) | |
download | gdb-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 'zlib/configure.ac')
0 files changed, 0 insertions, 0 deletions