From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17927 invoked by alias); 29 May 2003 17:18:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17883 invoked from network); 29 May 2003 17:18:25 -0000 Received: from unknown (HELO sun.netezza.com) (209.113.240.37) by sources.redhat.com with SMTP; 29 May 2003 17:18:25 -0000 Received: from astral (host20 [192.168.0.20]) by sun.netezza.com (8.12.9+Sun/8.12.9) with SMTP id h4THINTA025168; Thu, 29 May 2003 13:18:23 -0400 (EDT) Message-ID: <0eda01c32606$4f21a490$1400a8c0@astral> Reply-To: "John S. Yates, Jr." From: "John S. Yates, Jr." To: "Daniel Jacobowitz" Cc: "gdb" References: <0eb201c325e9$5fb63450$1400a8c0@astral> <20030529152702.GA10363@nevyn.them.org> <0ec201c325fb$764554a0$1400a8c0@astral> <20030529160927.GA11795@nevyn.them.org> Subject: Re: malloc in inferior Date: Thu, 29 May 2003 17:18:00 -0000 Organization: Netezza Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-05/txt/msg00395.txt.bz2 From: "Daniel Jacobowitz" [..SNIP..] > > Is there anything short of calling a function in the > > target that requires materialization in the inferior? > > I can perform an enormous amount of debugging without > > ever thinking about trying to call a function. > > What can you usefully do with strings that doesn't communicate them to > the inferior? > > For instance, assigning "set x = "abc"" must materialize it in the > inferior. Well as it so happens I was writing a "user-defined command" to walk from a task control block out 3 levels. My command had to guard against instances when outer levels of the structure did not exist. In such cases it tried to provide a clear diagnostic. The task control block contains an char tcb_name[8] member. Since at times there might not even be a task running there might not be a valid task name. Thus I had $task_name = "" // even this calls malloc $tcb = 0 $ptr1 = 0 $ptr2 = 0 if TCD_Current_Task $tcb = TCD_Current_Task $task_name = TCD_Current_Task->tcb_name else printf "no current task\n" end if $tcb $ptr1 = $tcb->tcb_ptr1 if ! $ptr1 print "task %s: tcb_ptr1 is null\n",$task_name end end if $ptr1 $ptr2 = $ptr1->xxx_ptr2 if ! $ptr2 print "task %s: xxx_ptr2 is null\n",$task_name end end ... [..SNIP..] > > I think this suggestion got missed. Instead of today's > > immediate materialization in the inferior against the > > possibility that the value might be required there in > > the future why not use a lazy approach? Before calling > > an inferior function push down any accessible objects. > > I didn't miss it; see above. It would have to happen every time the > inferior is _resumed_, too. No. An object is only accessible in the inferior if its address has been 1) manifested (always true for string literals) 2) supplied to the inferior via assignment (to inferior storage) or as an argument to an inferior function call [..SNIP..] > > This may be the case for the first suggestion. The > > second was that gdb have access to a chunk of memory > > that it manages itself. That is the allocation and > > freeing would operator on structures in gdb's address > > space, only the actual memory would exist in the > > inferior. In a remote stub the block of memory might > > simply be a large static array. > > Which would, in a protected memory system, have to be allocated in the > child anyway. And you can't call malloc() before program > initialization necessarily. Under the lazy paradigm gdb would grab any memory in the inferior until it knew that it needed to. In the case of the protected memory system, where possible, an anonymous mmap call grabbing a few megabytes might be significantly less invasive. /john