Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Wu Zhou <woodzltc@cn.ibm.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: drow@false.org, gdb@sources.redhat.com
Subject: Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion?
Date: Fri, 04 Nov 2005 03:15:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.63.0511041048590.22104@linux.site> (raw)
In-Reply-To: <200511032134.jA3LYDsT017248@elgar.sibelius.xs4all.nl>

Hi Mark,

On Thu, 3 Nov 2005, Mark Kettenis wrote:

> > Date: Thu, 3 Nov 2005 11:14:51 +0800 (CST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > 
> > Maybe we can convert the argument to its pointer before we enter into
> > call_function_by_hand (evaluate_subexp_standard: case OP_FUNCALL)?  
> > Normally what function you will use to allocate memory on the stack?  I am 
> > not very familar with that kind of code.  Thanks!
> 
> Allocating memory on the stack is actually quite eazy.  Just
> substract/add the amount of space you need from/to the stack pointer,
> and use the new/old stack pointer as the address for the memory.
> Whether you should substract or add depends on whether the stack grows
> downward or upward.  Use gdbarch_inner_than(gdbarch, 1, 2) to check.
> There's quite a bit of code in infcall.c that uses this trick.
> 

Thanks.  I did some tests following this way.  But didn't get any success. 
So I had to post here again to see if anybody can help me out.  

My basic idea is to create a value which hold the address to the original 
argument. This is done in valur_addr for these argument which is not lval 
and whose type is TYPE_CODE_INT.  Then I use the above method to get a new 
value which hold the address to the original address.  Although it doesn't 
report SEGV or "can not access memory" message, it didn't ouptut the 
correct result I expected.  I expect 4 (which is 2 * 2), but it return 
different number for me every time I run it.

Following is the changed I made to valur_arg_coerce and value_addr.  Could 
anyone help me pointed out what is the reason why it fail.  Thanks a lot!

Index: infcall.c
===================================================================
RCS file: /cvs/src/src/gdb/infcall.c,v
retrieving revision 1.73
diff -c -3 -p -r1.73 infcall.c
*** infcall.c	2 Sep 2005 19:02:44 -0000	1.73
--- infcall.c	4 Nov 2005 03:11:35 -0000
*************** value_arg_coerce (struct value *arg, str
*** 109,114 ****
--- 109,115 ----
    switch (TYPE_CODE (type))
      {
      case TYPE_CODE_REF:
+     case TYPE_CODE_PTR:
        if (TYPE_CODE (arg_type) != TYPE_CODE_REF
  	  && TYPE_CODE (arg_type) != TYPE_CODE_PTR)
  	{
*************** value_arg_coerce (struct value *arg, str
*** 154,160 ****
  	  type = lookup_pointer_type (TYPE_TARGET_TYPE (type));
        break;
      case TYPE_CODE_UNDEF:
-     case TYPE_CODE_PTR:
      case TYPE_CODE_STRUCT:
      case TYPE_CODE_UNION:
      case TYPE_CODE_VOID:
--- 155,160 ----
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.161
diff -c -3 -p -r1.161 valops.c
*** valops.c	27 May 2005 04:39:32 -0000	1.161
--- valops.c	4 Nov 2005 03:11:49 -0000
*************** value_addr (struct value *arg1)
*** 868,877 ****
      }
    if (TYPE_CODE (type) == TYPE_CODE_FUNC)
      return value_coerce_function (arg1);
! 
    if (VALUE_LVAL (arg1) != lval_memory)
      error (_("Attempt to take address of value not located in memory."));
  
    /* Get target memory address */
    arg2 = value_from_pointer (lookup_pointer_type (value_type (arg1)),
  			     (VALUE_ADDRESS (arg1)
--- 868,905 ----
      }
    if (TYPE_CODE (type) == TYPE_CODE_FUNC)
      return value_coerce_function (arg1);
! /*
    if (VALUE_LVAL (arg1) != lval_memory)
      error (_("Attempt to take address of value not located in memory."));
+ */
+ 
+   if (TYPE_CODE (type) == TYPE_CODE_INT  && VALUE_LVAL (arg1) == not_lval)
+     {
+       int len = TYPE_LENGTH (type);
+       CORE_ADDR addr;
+       CORE_ADDR sp = read_sp ();
+       if (INNER_THAN (1, 2))
+ 	{
+ 	  /* stack grows downward */
+ 	  sp -= len;
+ 	  /* ... so the address of the thing we push is the
+ 	     stack pointer after we push it.  */
+ 	  addr = sp;
+ 	}
+       else
+ 	{
+ 	  /* The stack grows up, so the address of the thing
+ 	     we push is the stack pointer before we push it.  */
+ 	  addr = sp;
+ 	  sp += len;
+ 	}
+ 
+       addr = (CORE_ADDR) malloc (len);
+       write_memory (addr, value_contents_all (arg1), len);
+       arg2 = value_from_pointer (lookup_pointer_type (type), addr);
  
+       return arg2;
+     }
    /* Get target memory address */
    arg2 = value_from_pointer (lookup_pointer_type (value_type (arg1)),
  			     (VALUE_ADDRESS (arg1)


Regards
- Wu Zhou


  reply	other threads:[~2005-11-04  3:15 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 [this message]
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
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.0511041048590.22104@linux.site \
    --to=woodzltc@cn.ibm.com \
    --cc=drow@false.org \
    --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