From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32269 invoked by alias); 21 Sep 2002 00:55:36 -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 32261 invoked from network); 21 Sep 2002 00:55:35 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 21 Sep 2002 00:55:35 -0000 Received: from dberlin.org (pool-138-88-150-10.esr.east.verizon.net [138.88.150.10]) by mail.cdt.org (Postfix) with ESMTP id 7C13249002D; Fri, 20 Sep 2002 20:32:50 -0400 (EDT) Received: from [192.168.0.252] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.0b8) with ESMTP id 90100; Fri, 20 Sep 2002 20:55:34 -0400 Date: Fri, 20 Sep 2002 17:55:00 -0000 Subject: Re: xmmalloc? Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Daniel Jacobowitz , David Carlton , Kevin Buettner , gdb To: Andrew Cagney From: Daniel Berlin In-Reply-To: <3D8BBA3C.1080306@ges.redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00335.txt.bz2 On Friday, September 20, 2002, at 08:15 PM, Andrew Cagney wrote: >> On Fri, Sep 20, 2002 at 03:55:14PM -0700, David Carlton wrote: >>> Does GDB currently use xmmalloc in any consistent way? When writing >>> functions that might call xmalloc, should I try to write versions >>> that >>> call xmmalloc instead and try to find an appropriate md to pass to >>> them? If I don't do that but instead just use xmalloc, will anything >>> bad happen? In particular, am I opening up myself to any new >>> possible memory leaks, other than the ones that are, of course, >>> always >>> possible when calling xmalloc? >>> Any background info on this would be appreciated. >> I get the distinct impression that uses of mmalloc have started to >> rot... >> If this is not the case, could someone please summarize the >> advantages? Otherwise, should we just remove it entirely? > > The offical line is that ``we're'' removing it entirely. The ARI says > ``GDB is trying to eliminate the [x]mmalloc() family.'' so it must be > true ... :-^ > > (No I don't remember exactly when this was discusssed. Its' one of > those things that was drummed into me from long long ago :-) > > It would mean that GDB could no longer be compiled to pull the ``use > mmap to save sections trick'' but I gather from the discussion (I > don't remember) that this was acceptable. > It was my impression that Apple's GDB used this extensively. (Both mmalloc, and the mmap cached symfiles trick). They even have a script that updates the cached files when the libraries change. I have 53 meg of cached syms for various libraries in /usr/libexec/gdb/symfiles on my Mac. [dberlin2:/usr/libexec/gdb] dberlin# ./cache-symfiles Removing current cache ... done GNU gdb 5.1-20020408 (Apple version gdb-231) (Tue Aug 13 21:37:39 GMT 2002) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-macos10". (gdb) Reading symbols from /private/tmp/syms_5748...done. Reading symbols for shared libraries ........................................................................ ........................................................................ . done <....> (gdb) Mapping "/usr/libexec/gdb/symfiles/dyld.syms" at 0xc0000000 ... endpoint is 0xc002b000 Mapping "/usr/libexec/gdb/symfiles/AGL.syms" at 0xc002b000 ... endpoint is 0xc0053000 Mapping "/usr/libexec/gdb/symfiles/AddressBook.syms" at 0xc0053000 ... endpointis 0xc00d5000 Mapping "/usr/libexec/gdb/symfiles/AppKit.syms" at 0xc00d5000 ... endpoint is 0xc037a000 <....> And looking at the source to apple's gdb shows they added a *ton* of mmalloc uses to do this. It works too, unlike the current "mmap the syms" stuff. > Andrew > >