Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!chinacat!bigtex!james
From: james@bigtex.cactus.org (James Van Artsdalen)
Newsgroups: gnu.gdb.bug
Subject: Re: gdb3.5 & malloc(3c)
Message-ID: <31297@bigtex.cactus.org>
Date: 26 Feb 90 04:18:02 GMT
References: <1659@aber-cs.UUCP>
Reply-To: james@bigtex.cactus.org (James Van Artsdalen)
Distribution: gnu
Organization: Institute of Applied Cosmology, Austin TX
Lines: 35

In <1659@aber-cs.UUCP>, pcg@cs.aber.ac.uk (Piercarlo Grandi) wrote:

> Malloc()s like the GNU one that are based on the Caltech one use a kind
> of buddy system, in the vain hope this will make them fast. The only
> result is that they become much less space efficient.

For the record, on SysVr3.2, i386v, I got the following results
running gdb on cc1, compiled with full debugging.  A page is 4K bytes.

Which malloc	Pages	 CPU
------------	-----	 ---
GNU malloc	1466	 :23
libc malloc	 780	1:45
-lmalloc	 762	 :25

My recommendation is to just have SysV set GNU_MALLOC to -lmalloc for
now.  In the meantime, someone should volunteer to fix GNU malloc.
gdb doesn't have a bug as far as I am concerned, although one fix
might be to use a special "malloc" for reading in the symbol table, or
to just use brk(2).

> Another thing, entirely different: I will be posting shortly some simple
> patches to GDB main.c that avoid including readline and company. This
> library consumes about 30% of the code space of GDB.

On my system, it hardly seems worth the effort:

$ size *.o
funmap.o: 400 + 1140 + 0 = 1540
history.o: 6792 + 228 + 0 = 7020
keymaps.o: 532 + 3108 + 0 = 3640
readline.o: 19920 + 1020 + 0 = 20940
-- 
James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789