This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: partial symbol table address range generalization
- To: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: RFC: partial symbol table address range generalization
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 07 Nov 2001 23:23:08 -0500
- Cc: Daniel Jacobowitz <drow at mvista dot com>,gdb-patches at sources dot redhat dot com
- References: <20011023233450.09F855E9D8@zwingli.cygnus.com> <20011023195430.A15242@nevyn.them.org> <npsnc965cl.fsf@zwingli.cygnus.com> <20011101181555.C18222@nevyn.them.org> <np1yjaouf0.fsf@zwingli.cygnus.com>
> The question is, how can you represent this in an obstack-friendly
> way? The obvious representation of an addrmap is a sorted array, with
> a gap for insertion, but obstacks don't like arrays that expand
> occasionally. A doubling algorithm can guarantee that the waste is
> merely proportional to the final size, but that's kind of crummy. A
> binary tree works better, but you spend a lot of memory on child
> links; we wouldn't want to use an addrmap to store line number info if
> it took twenty bytes per line (currently it takes only twelve) (both
> assuming a 64-bit CORE_ADDR and 32-bit pointers and ints).
You mean a b-tree?
Andrew