Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfa] Add a name field to ``struct floatformat''
Date: Tue, 30 May 2000 16:42:00 -0000	[thread overview]
Message-ID: <1000530234235.ZM5405@ocotillo.lan> (raw)
In-Reply-To: <3934454E.AAB68F28@cygnus.com>

On May 31,  8:48am, Andrew Cagney wrote:

> Did you like how GDB added floatformat_to_double() to libiberty and then
> replaced that with a local floatformat_to_doublest() ;-/

I noticed it, but did not know how it came about.  Who's responsible
for maintaining libiberty?

The reason I ask is that I've been wondering what to do about the fact
that we now have a number of fixes to floatformat_to_doublest() and
floatformat_from_doublest() (or their helper functions) and that these
have not (to the best of my knowledge) been merged into libiberty.

The ones that I know about are:

	* utils.c (get_field, put_field): Fix buffer underruns and
	overruns.  Also, handle case where total_len is not evenly
	divisible by 8.
	(getfield): Make sure zeroing of unwanted bits occurs even
	when bit field to extract does not straddle two or more
	bytes.

	* utils.c (floatformat_from_doublest): Don't assume that a long
	will be exactly 32 bits in length.  Also...  make sure space
	that we're writing the float to is completely initialized to
	zeroes, even when the number of bits in the float is not
	evenly divisible by FLOATFORMAT_CHAR_BIT.

Kevin
From dan@cgsoftware.com Tue May 30 17:23:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [RFA] Reduce memory usage for dwarf2 dramatically, unify hashfunctions
Date: Tue, 30 May 2000 17:23:00 -0000
Message-id: <Pine.LNX.4.10.10005301704450.27990-200000@propylaea.anduin.com>
X-SW-Source: 2000-05/msg00475.html
Content-length: 1587

This patch dramatically reduces memory usage when using DWARF2. It
should also make debugging with DWARF2 quicker because of what it
is doing. Before, we would allocate a new type every time we saw a type,
or close to it.
With this patch, we cache the last 4096 (it's controlled by a define, this
is a completely unscientific number, you could probably do with smaller,
but it won't make much difference, seeing as how it's 16k worth of
pointers) types we saw by the hash of their name, and use that, rather
than allocating a new type every time.
The results are dramatic.
Just on GDB, compiled with dwarf2, for instance, we go from 123,739 types
to 87,004, a 33% reduction. We also drop from needing 60 meg, with
everything read in (maint check symtabs was used to force readin), to 46
meg.

Since their are now really only "distinct" symbols, and "distinct" types,
rather than tons of duplicates, things should go a bit faster as well in
other lookups.

In doing all of this, i also changed the hash function in the bcache to a
much better hash function (the old one was stolen from SDBM, this one uses
what db 3.0.55 uses. The commentary in the db 3.0.55 source says it's just
as good on strings, and much better on numbers), made the hash function
available through bcache.h, and changed buildsym.c's hashname to use it as
well.

I was going to change the minsym hash to use the hash function as well,
but haven't finished regression tests on that change, so i left it out.

I'm just starting to clear out my backlog of patches, expect more memory
reductions for dwarf2 soon.
--Dan


       reply	other threads:[~2000-05-30 16:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3933676F.676D861C@cygnus.com>
     [not found] ` <1000530153706.ZM32196@ocotillo.lan>
     [not found]   ` <3934454E.AAB68F28@cygnus.com>
2000-05-30 16:42     ` Kevin Buettner [this message]
2000-05-30 19:18       ` Andrew Cagney
     [not found] ` <3933695B.6CE1380D@cygnus.com>
2000-05-31  3:58   ` Andrew Cagney
     [not found] <9703.959716280@upchuck>
2000-05-30 15:47 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1000530234235.ZM5405@ocotillo.lan \
    --to=kevinb@cygnus.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox