This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: The root cause for SEGV in evaluating fortran function call,any solution or suggestion?
Hi Mark,
On Wed, 2 Nov 2005, Mark Kettenis wrote:
> What you describe sounds very similar to what
> gdbarch_stabs_argument_has_addr is all about. Currently these are
> only used on SPARC, and only for stabs.
Thanks for your pointer. It looks very much like the same (If I understand
correctly :-). Look at the following testcase please:
PROGRAM funcall
integer a, b
b = 2
a = res(b)
END PROGRAM
function res(m)
integer m
integer res
res = m * m
end function
The debuginfo for function res is like this:
<1><da>: Abbrev Number: 7 (DW_TAG_subprogram)
DW_AT_sibling : <10f>
DW_AT_external : 1
DW_AT_name : res_
DW_AT_decl_file : 1
DW_AT_decl_line : 23
DW_AT_type : <bb>
DW_AT_low_pc : 0x804863f
DW_AT_high_pc : 0x8048655
DW_AT_frame_base : 1 byte block: 55 (DW_OP_reg5)
<2><f5>: Abbrev Number: 8 (DW_TAG_formal_parameter)
DW_AT_name : m
DW_AT_type : <10f> =====> This is a const pointer to integer
DW_AT_artificial : 1
DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8)
<1><10f>: Abbrev Number: 9 (DW_TAG_const_type)
DW_AT_type : <114>
<1><114>: Abbrev Number: 10 (DW_TAG_pointer_type)
DW_AT_byte_size : 4
DW_AT_type : <bb>
<1><bb>: Abbrev Number: 6 (DW_TAG_base_type)
DW_AT_name : integer
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
So my question is: how will gdb to handle this situation if the gdbarch
shows that stabs argument has addr, especially when the command line pass
an integer type, but the debuginfo said that it need a pointer?
>
> One could argue that the debug information generated by g77 is wrong,
> because it doesn't reflect the actual implementation of FUNC_NAME. Or
> perhaps GDB symbol reading code causes problems. Can you post a
> concrete example of a function call that goes wrong, and add a bit of
> explanation about the types involved for those of us who are not very
> familiar with Fortran?
Both of your arguments seem reasonable. But even in the first argument it
might also be desirable that we could handle it gracefully, right?
Here is the debugging session for the above testcase (maybe I could
convert it into a real testcase for gdb testsuite?), hoping that
it could clarify the things a little.
(gdb) r
Starting program: /root/DE/gdb-6.3/gdb/testsuite/gdb.fortran/func-call
Breakpoint 1, MAIN__ () at func-call.f:19
19 b = 2
Current language: auto; currently fortran
(gdb) n
20 a = res(b)
(gdb) p res (2)
No symbol "res" in current context.
(gdb) p res_ (2) =========> Use constand '2' as argument, get SEGV
Program received signal SIGSEGV, Segmentation fault.
0x08048648 in res_ (m=0x2) at func-call.f:26
26 res = m * m
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (res_) will be
abandoned.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/DE/gdb-6.3/gdb/testsuite/gdb.fortran/func-call
Breakpoint 1, MAIN__ () at func-call.f:19
19 b = 2
(gdb) n
20 a = res(b)
(gdb) p res_ (b) =========> Use variable 'b' as argument, get SEGV
Program received signal SIGSEGV, Segmentation fault.
0x08048648 in res_ (m=0x2) at func-call.f:26
26 res = m * m
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (res_) will be
abandoned.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/DE/gdb-6.3/gdb/testsuite/gdb.fortran/func-call
Breakpoint 1, MAIN__ () at func-call.f:19
19 b = 2
(gdb) n
20 a = res(b)
(gdb) p res_ (&b) ========> Use '&b' as argument, get correct result
$1 = 4
Regards
- Wu Zhou