From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18310 invoked by alias); 29 May 2003 16:00:47 -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 18276 invoked from network); 29 May 2003 16:00:46 -0000 Received: from unknown (HELO sun.netezza.com) (209.113.240.37) by sources.redhat.com with SMTP; 29 May 2003 16:00:46 -0000 Received: from astral (host20 [192.168.0.20]) by sun.netezza.com (8.12.9+Sun/8.12.9) with SMTP id h4TG0iTA021240; Thu, 29 May 2003 12:00:44 -0400 (EDT) Message-ID: <0ec201c325fb$764554a0$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> Subject: Re: malloc in inferior Date: Thu, 29 May 2003 16:00: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/msg00390.txt.bz2 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. > > 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. > > 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. > 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. /john