From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12020 invoked by alias); 7 Nov 2005 00:09:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 12002 invoked by uid 22791); 7 Nov 2005 00:09:55 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 07 Nov 2005 00:09:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EYua6-0005IR-10; Sun, 06 Nov 2005 19:09:50 -0500 Date: Mon, 07 Nov 2005 00:09:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion? Message-ID: <20051107000949.GD19200@nevyn.them.org> Mail-Followup-To: Wu Zhou , Mark Kettenis , gdb@sources.redhat.com References: <20051102145258.GA28372@nevyn.them.org> <200511032134.jA3LYDsT017248@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-11/txt/msg00127.txt.bz2 On Fri, Nov 04, 2005 at 11:18:00AM +0800, Wu Zhou wrote: > > 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! It's not quite as simple as Mark makes it out to be - in concept, sure, but not in execution. You have to _allocate_ the space on the stack; not just find empty space off the side of the stack and write the argument there. By the type that we're calling value_arg_coerce, we've already allocated some space on the stack, and saved the old stack pointer. But we'll allocate more space on the stack below, when we push arguments. And you have to be careful to keep the stack aligned properly through all of this. Read through the surrounding bits of infcall.c to see how this works for struct returns; that is the closest analogue we have today. Maybe if you pass the sp value by reference to value_arg_coerce and adjust it there... -- Daniel Jacobowitz CodeSourcery, LLC