This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
- From: Doug Evans <dje at google dot com>
- To: gdb-patches <gdb-patches at sourceware dot org>
- Date: Fri, 13 Jul 2012 17:06:49 -0700
- Subject: Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
- References: <20120709181015.2FCA41E13A1@ruffy2.mtv.corp.google.com> <CADPb22Q=qT4AHoOo8cT1joKFziZqkzNFFTTP76_WDarV6mS+zg@mail.gmail.com>
On Fri, Jul 13, 2012 at 11:52 AM, Doug Evans <dje@google.com> wrote:
> Hi. "ping" [for the libiberty part]
>
> [The gdb part needs to be updated due to recent changes there, but I'm
> going to wait until the libiberty part is approved.]
>
> On Mon, Jul 9, 2012 at 11:10 AM, Doug Evans <dje@google.com> wrote:
>> Hi.
>>
>> filename_seen in gdb does a linear search, this patch changes it
>> to use a hash table.
>>
>> Ok to check in?
>>
>> I couldn't think of a good reason to put filename_hash,filename_eq in gdb,
>> and I like placing them close to where hashtab.c and filename_cmp are defined.
>> I also couldn't think of a sufficient reason to put them in a file by
>> themselves. Ergo adding them to filename_cmp.c, filenames.h.
>> [It's possible there's a program that uses filename_cmp and already
>> defines functions with the same names (thus this will introduce a build
>> failure), but that's always a risk. I couldn't find any in gdb,binutils,gcc.
>> Technically speaking, it's also possible that adding the #include "hashtab.h"
>> to filenames.h could introduce a build failure (e.g., some file has a static
>> symbol that collides with one used in hashtab.h). I'm hoping that's more of
>> a theoretical concern.]
>>
>> 2012-07-09 Doug Evans <dje@google.com>
>>
>> include/
>> * filenames.h: #include "hashtab.h".
>> (filename_hash, filename_eq): Declare.
>>
>> libiberty/
>> * filename_cmp.c (filename_hash, filename_eq): New functions.
>>
>> gdb/
>> * symtab.c (filename_seen): Rewrite to use a hash table.
With the libiberty part done, here's the updated gdb side.
As data, using my standard large app for exercising gdb issues, and
after running it a few times to warm the disk cache (for the fullname
conversion):
gdb $program # uses .gdb_index v7
(gdb) mt time 1
(gdb) info sources #1
(gdb) info sources #2
Before (best of 3):
#1: 18.100000 (cpu), 18.666510 (wall)
#2: 7.580000 (cpu), 7.936617 (wall)
After (best of 3):
#1: 10.060000 (cpu), 10.912673 (wall)
#2: 0.280000 (cpu), 2.746012 (wall)
Ok to check in?
2012-07-13 Doug Evans <dje@google.com>
* symtab.c (filename_seen_cache): Delete members "tab_alloc_size",
"tab_cur_size". Change member "tab" to be a htab_t.
(create_filename_seen_cache): Update.
(clear_filename_seen_cache, delete_filename_seen_cache): Update.
(filename_seen): Update.