public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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

  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).