xmmalloc?

xmmalloc?

[David Carlton]

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.

David Carlton
carlton@math.stanford.edu

Re: xmmalloc?

[Daniel Jacobowitz]

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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: xmmalloc?

[Kevin Buettner]

On Sep 20,  3:55pm, David Carlton wrote:

> Does GDB currently use xmmalloc in any consistent way?

It may have at one time, but I don't think it does any longer.

> 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?

In my opinion, we should just use xmalloc().

> Any background info on this would be appreciated.

See http://sources.redhat.com/gdb/5/onlinedocs/mmalloc.html

Basically, mmalloc was a library which used mmap() for doing
allocations.  If done right, this could be used to implement a saved
state mechanism, but I don't think we've been careful enough in GDB in
recent years for this stuff to still work.  If someone knows if it
ever worked I'd like to hear about the capabilities that it gave
GDB.

Re: xmmalloc?

[Kevin Buettner]

On Sep 20,  7:16pm, Daniel Jacobowitz wrote:

> 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? 

Yes, I'd like to see this too.

> Otherwise, should we just remove it entirely?

If no one makes a convincing case for it, I think it should be removed.
It'd make the code in utils.c simpler...

Kevin

Re: xmmalloc?

[David Carlton]

On Fri, 20 Sep 2002 16:33:41 -0700, Kevin Buettner <kevinb@redhat.com> said:
> On Sep 20,  7:16pm, Daniel Jacobowitz wrote:

>> Otherwise, should we just remove [xmmalloc] entirely?

> If no one makes a convincing case for it, I think it should be
> removed.

That's what I was hoping y'all would say!  I'd be happy to volunteer
to remove it if the consensus turns out to be that that would be a
good idea.  Not that I don't like adding new code to software, mind
you, but deleting code has its undeniable pleasures...

David Carlton
carlton@math.stanford.edu

Re: xmmalloc?

[Andrew Cagney]

> 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.

Andrew

Re: xmmalloc?

[Daniel Berlin]

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
>
>