From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6562 invoked by alias); 29 May 2003 16:09:35 -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 6550 invoked from network); 29 May 2003 16:09:34 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 29 May 2003 16:09:34 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19LPyj-0003p5-00; Thu, 29 May 2003 11:10:09 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19LPy3-00034g-00; Thu, 29 May 2003 12:09:27 -0400 Date: Thu, 29 May 2003 16:09:00 -0000 From: Daniel Jacobowitz To: "John S. Yates, Jr." Cc: gdb Subject: Re: malloc in inferior Message-ID: <20030529160927.GA11795@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ec201c325fb$764554a0$1400a8c0@astral> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00391.txt.bz2 On Thu, May 29, 2003 at 12:00:44PM -0400, John S. Yates, Jr. wrote: > > From: "Daniel Jacobowitz" > To: "John S. Yates, Jr." > Cc: "gdb" > Sent: Thursday, May 29, 2003 11:27 AM > Subject: Re: malloc in inferior > > > > On Thu, May 29, 2003 at 09:51:15AM -0400, John S. Yates, Jr. wrote: > > [..SNIP..] > > > > Why can gdb not allocate values within its own > > > address space? > > > > Because it's not useful to do so. Sure, trivial examples like > > print "foo" could be done this way; and it would be nice to do that. > > But to do anything more complicated requires materializing them in the > > inferior. Some optimization is missing but you can't get away from the > > problem that way. > > 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. > > > I understand that to support calling functions > > > in the inferior gdb may have to materialize > > > values there. But these should be pushed into > > > the inferior once it is clear that they need to > > > exist there. > > 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. > > > And how can gdb possibly debug a multi-threaded > > > application with a thread-safe malloc? > > > > This wasn't considered in the current design, true. I'm open to > > suggestions. > > > > > One possibility would be to add malloc and free > > > messages to the remote protocol. Then a stub > > > could allocation memory in the proper address > > > space without interacting with the inferior's > > > environment. > > > > > > Another would be to have a stub provide a block > > > of memory. A query would determine the address > > > and size of this block. Then gdb could manage > > > the memory entirely on its own. > > > > For some stubs these would be useful; for the stubs I deal with, which > > sit in user space on normal OS's, rather less so. The stub would end > > up calling malloc anyway. > > 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. > > Personally, I'm of the opinion that we should solve this problem by > > changing the definitions: mark strings as ephemeral and let the user > > call malloc or strdup directly if they want something to last. Or make > > it a set option. I'm not sure how popular that idea would be; anyone > > else have a comment? > > The problem is more general than just strings. Care to give another example of when GDB calls malloc? Strings are far and away the most common. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer