Andrew Burgess
aa19bc1d25
I noticed in passing that out algorithm for generating the gdb-index file is incorrect. When building the hash table in add_index_entry we count every incoming entry rehash when the number of entries gets too large. However, some of the incoming entries will be duplicates, which don't actually result in new items being added to the hash table. As a result, we grow the gdb-index hash table far too often. With an unmodified GDB, generating a gdb-index for GDB, I see a file size of 90M, with a hash usage (in the generated index file) of just 2.6%. With a patched GDB, generating a gdb-index for the _same_ GDB binary, I now see a gdb-index file size of 30M, with a hash usage of 41.9%. This is a 67% reduction in gdb-index file size. Obviously, not every gdb-index file is going to see such big savings, however, the larger a program, and the more symbols that are duplicated between compilation units, the more GDB would over count, and so, over-grow the index. The gdb-index hash table we create has a minimum size of 1024, and then we grow the hash when it is 75% full, doubling the hash table at that time. Given this, then we expect that either: a. The hash table is size 1024, and less than 75% full, or b. The hash table is between 37.5% and 75% full. I've include a test that checks some of these constraints -- I've not bothered to check the upper limit, and over full hash table isn't really a problem here, but if the fill percentage is less than 37.5% then this indicates that we've done something wrong (obviously, I also check for the 1024 minimum size). Approved-By: Tom Tromey <tom@tromey.com>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.