From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27947 invoked by alias); 29 May 2003 15:27:07 -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 27937 invoked from network); 29 May 2003 15:27:07 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 29 May 2003 15:27:07 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19LPJe-0003jw-00; Thu, 29 May 2003 10:27:42 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19LPJ0-0002oG-00; Thu, 29 May 2003 11:27:02 -0400 Date: Thu, 29 May 2003 15:27:00 -0000 From: Daniel Jacobowitz To: "John S. Yates, Jr." Cc: gdb Subject: Re: malloc in inferior Message-ID: <20030529152702.GA10363@nevyn.them.org> Mail-Followup-To: "John S. Yates, Jr." , gdb References: <0eb201c325e9$5fb63450$1400a8c0@astral> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0eb201c325e9$5fb63450$1400a8c0@astral> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00387.txt.bz2 On Thu, May 29, 2003 at 09:51:15AM -0400, John S. Yates, Jr. wrote: > I have finally figured out that the reason gdb > keeps crashing my embedded system is that it > tries to call malloc at the drop of a hat. > > There are various contexts in our code where > performing a memory allocation is disallowed. > This is enforced by our allocation primitives. > > Our system does not uses malloc. The malloc > that is part of the c-runtime calls through a > null function pointer, triggering a machine > reset. So something as simple as > > (gdb) print "foo" > > causes a crash. > > 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. > 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. > > 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. 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? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer