From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1010 invoked by alias); 29 May 2003 17:24:11 -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 992 invoked from network); 29 May 2003 17:24:10 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 29 May 2003 17:24:10 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19LR8w-0003ya-00; Thu, 29 May 2003 12:24:46 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19LR8H-0006MA-00; Thu, 29 May 2003 13:24:05 -0400 Date: Thu, 29 May 2003 17:24:00 -0000 From: Daniel Jacobowitz To: "John S. Yates, Jr." Cc: gdb Subject: Re: malloc in inferior Message-ID: <20030529172404.GA24128@nevyn.them.org> Mail-Followup-To: "John S. Yates, Jr." , gdb References: <0eb201c325e9$5fb63450$1400a8c0@astral> <20030529152702.GA10363@nevyn.them.org> <0ec201c325fb$764554a0$1400a8c0@astral> <20030529160927.GA11795@nevyn.them.org> <0eda01c32606$4f21a490$1400a8c0@astral> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0eda01c32606$4f21a490$1400a8c0@astral> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00396.txt.bz2 On Thu, May 29, 2003 at 01:18:23PM -0400, John S. Yates, Jr. wrote: > 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..] Hmm. This might be possible. Again, do you have a concrete example where GDB calls malloc() other than strings? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer