From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12161 invoked by alias); 19 Mar 2007 20:08:29 -0000 Received: (qmail 12133 invoked from network); 19 Mar 2007 20:08:13 -0000 Received: from unknown (212.77.101.9) by sourceware.org with QMTP; 19 Mar 2007 20:08:13 -0000 Received: (wp-smtpd smtp.wp.pl 18712 invoked from network); 19 Mar 2007 21:08:03 +0100 Received: from host86-128-14-58.range86-128.btcentralplus.com (HELO BIGOS) (jagorak@[86.128.14.58]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 19 Mar 2007 21:08:03 +0100 Date: Mon, 19 Mar 2007 20:08:00 -0000 From: jagorak X-Mailer: Private Mailer 1.0 Reply-To: jagorak Message-ID: <1905422578.20070319200802@wp.pl> To: Daniel Jacobowitz , Joel Brobecker CC: gdb@sourceware.org Subject: Re[2]: Calling an Ada subprogram with complex parameters In-Reply-To: <20070319021557.GA26173@caradoc.them.org> References: <1827236609.20070317231124@wp.pl> <20070319021557.GA26173@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00221.txt.bz2 >> where $myRec is a convenience variable of type "Rec", but this >> wouldn't work either since convenience variable resides in >> gdb-specific memory space, complex types seem to be passed by >> reference and myProc cannot access memory address of $myRec. DJ> Actually, that's not true - convenience variables which have a DJ> memory location are put into the target's memory. Sometimes GDB DJ> uses the stack, other times malloc is called under the hood. That is very good news to me, as using absolute addressess is much less convenient than using convenience variables. HOWEVER, GDB is complaining when I try to use convenience variable in a subprogram call, whereas it is not complaining when I give it an absolute address. (This is why I thought convenience variables were not stored in target memory). Let me explain. Assuming Rec is a type as defined in my previous posts, using absolute address I can set data & make a call as follows (this is actually the solution to my problem I described in my original post). (gdb) set ({Rec} 0xABCDEF00).a := false (gdb) set ({Rec} 0xABCDEF00).b := 55 (gdb) call myProc({Rec} *0xABCDEF00)) ABOVE WORKS FINE. Now, when I use a convenience variable (still using absolute address but only as 'read-only-trick' to get the convenience variable to be set to the appropriate type), GDB is complaining. Here is the process: // The 'read-only-trick' to set $conVar to appropriate type (I'm // not bothered with the value of $conVar at that stage) // Address can be random and doesn't really matter here. (gdb) set $conVar := ({Rec} 0xABCDEF00) // set $conVar to what I want (gdb) set $conVar.a := false (gdb) set $conVar.b := 55 // ---> NOW - here is the problem: <---- (gdb) call myProc($conVar) gdb says: Attempt to take address of value not located in memory. I tried to work out what is the address of $conVar, as I would do with 'normal' variable, but it doesn't work: (gdb) p &$conVar gdb says: Attempt to take address of non-lval Which is curious - previously I was able to set the value of $conVar, but now it is complaining $conVar is not a non-lval. It seems that as if gdb treats each instance of a convenience variable in a command as the actual value which the variable holds. I think I need to have a better understanding of convenience variables. I'm not even sure whether I understand correctly what gdb says to me - your help is greatly appreciated! (coudn't work this out with the help of the gdb manual) Many, many thanks, Jan