From: Wu Zhou <woodzltc@cn.ibm.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb@sources.redhat.com
Subject: Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion?
Date: Thu, 03 Nov 2005 02:50:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.63.0511031016300.7578@linux.site> (raw)
In-Reply-To: <200511021551.jA2FpO7D009728@elgar.sibelius.xs4all.nl>
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
next prev parent reply other threads:[~2005-11-03 2:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-22 10:14 [GDB & Fortran] Anyone has success experience with printing the result of Fortran function calls? Wu Zhou
2005-11-02 2:39 ` The root cause for SEGV in evaluating fortran function call, any solution or suggestion? Wu Zhou
2005-11-02 14:53 ` Daniel Jacobowitz
2005-11-03 3:12 ` Wu Zhou
2005-11-03 21:34 ` Mark Kettenis
2005-11-04 3:15 ` Wu Zhou
2005-11-04 3:52 ` Wu Zhou
2005-11-07 0:09 ` Daniel Jacobowitz
2005-11-07 4:49 ` Wu Zhou
2005-11-07 5:01 ` Daniel Jacobowitz
2005-11-07 5:16 ` Wu Zhou
2005-11-10 0:55 ` Jim Blandy
2005-11-10 0:59 ` Daniel Jacobowitz
2005-11-11 9:59 ` Jim Blandy
2005-11-04 11:20 ` Dave Korn
2005-11-06 23:58 ` Daniel Jacobowitz
2005-11-02 15:51 ` Mark Kettenis
2005-11-03 2:50 ` Wu Zhou [this message]
2005-11-03 7:42 ` Jim Blandy
2005-11-03 10:16 ` Wu Zhou
2005-11-07 0:02 ` Daniel Jacobowitz
2005-11-10 0:49 ` Jim Blandy
2005-11-10 1:00 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.63.0511031016300.7578@linux.site \
--to=woodzltc@cn.ibm.com \
--cc=gdb@sources.redhat.com \
--cc=mark.kettenis@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).