[PATCH] Fix method naming bug in new DWARF indexer
Pedro Alves
pedro@palves.net
Tue Apr 26 18:40:22 GMT 2022
On 2022-04-25 19:27, Tom Tromey wrote:
> Pedro> The "much slower" aspect remains, this patch does not change it.
> Pedro> The size of the generated index roughly the same as from before
> Pedro> this patch, and it is still much larger than from before the new
> Pedro> DWARF indexer landed. I think that will require a separate fix.
> Pedro> I sent you more info
> Pedro> about it off list.
>
> I have a patch to fix the size problem. It works by only emitting a
> given type or variable once. This is what the gdb used to do via the
> psymbol bcache. It could sometimes mean that "info types" would miss
> a duplicate -- but the old code did this as well.
>
> I'll send this soon.
>
Thanks, I saw it on the list now, and I gave it a try.
> However, this patch doesn't fix the performance problem. I am not sure
> it is really fixable, given that the code has to compute the full name
> of every entry in the index.
>
Hmm, it actually fixes most of the performance for me. With that new patch (and I guess
the linkage names patch made a difference too), I see roughly the same startup time in
new gdb vs old gdb when using the same index, and either an index generated by old gdb, or
by new gdb. Generating the index is a bit slower than before, 7.1s vs 6.6s, a rough
8% slowdown, but then again, the generated index is still ~13% bigger than the one generated
by old gdb (17MB vs 15MB), which I assume explains the remaining index generation slowdown.
The patch you point at addresses variables/enums, and I wonder whether the remainder of size
increase (and thus the remainder of the slowdown) is explained by functions.
In the old indexer, with an index of a gdb from before the indexer rewrite, we had:
[369902] intrusive_list<inferior, intrusive_base_node<inferior> >::begin:
9 [global, function]
255 [global, function]
while in the new indexer, for the same function, we have:
[369902] intrusive_list<inferior, intrusive_base_node<inferior> >::begin:
9 [global, function]
79 [global, function]
165 [global, function]
167 [global, function]
252 [global, function]
253 [global, function]
254 [global, function]
255 [global, function]
263 [global, function]
266 [global, function]
310 [global, function]
311 [global, function]
373 [global, function]
376 [global, function]
396 [global, function]
436 [global, function]
503 [global, function]
506 [global, function]
507 [global, function]
513 [global, function]
Same with "make_scoped_restore<int, int>", for instance -- one entry in old index, and 21 entries
in new index.
Now, if I load that old gdb under new gdb, and set a breakpoint at one of those functions, I get
as many locations as entries in the old indexes. For example:
$ g="./gdb -data-directory=data-directory"
$ $g -nx /home/pedro/slowdown/gdb.before-indexer
[...]
(gdb) b intrusive_list<inferior, intrusive_base_node<inferior> >::begin
Breakpoint 2 at 0x555555c9aefe: intrusive_list<inferior, intrusive_base_node<inferior> >::begin. (2 locations)
^^^^^^^^^^^
Note the 2 locations found. "2" matches the number of entries in the old index for that function.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
2.1 y 0x0000555555c9aefe in intrusive_list<inferior, intrusive_base_node<inferior> >::begin() const
at ../../src/gdb/../gdbsupport/intrusive_list.h:521
2.2 y 0x00005555560ab946 in intrusive_list<inferior, intrusive_base_node<inferior> >::begin()
at ../../src/gdb/../gdbsupport/intrusive_list.h:516
Same for "make_scoped_restore<int, int>" -- setting a breakpoint there only finds one location,
just like there's only one entry for that function in the old index:
(gdb) b make_scoped_restore<int, int>
Breakpoint 1 at 0x83facc: file ../../src/gdb/../gdbsupport/scoped_restore.h, line 115.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000555555d93acc in make_scoped_restore<int, int>(int*, int) at ../../src/gdb/../gdbsupport/scoped_restore.h:115
If we used the same htab dedup logic as in your variables/enums patch, for functions, then we'd
end up with only a single entry in the index for the intrusive_list example, which seems incorrect.
What was the logic that the old writer used to come up with the seemingly right number of function entries?
> If we check in the background-writing code, this won't be noticeable for
> the index cache case. However, it will still be noticeable for
> "gdb-add-index".
For the time being, I'll continue using indexes, because as soon as you need to
run to a breakpoint from the command line, which I do all the time, then having an index still
beats the new scanner. E.g., for me:
g="./gdb -data-directory=data-directory"
$ time $g -q --batch -iex "set index-cache enabled off" $g -ex "start"
Setting up the environment for debugging gdb.
Breakpoint 1 at 0xa364b4: file /home/pedro/gdb/binutils-gdb/src/gdbsupport/errors.cc, line 51.
Breakpoint 2 at 0x260fa3: file /home/pedro/gdb/binutils-gdb/src/gdb/cli/cli-cmds.c, line 217.
Temporary breakpoint 3 at 0xeb06c: file /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c, line 25.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 3, main (argc=1, argv=0x7fffffffdc48) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:25
25 {
real 0m3.920s
user 0m6.924s
sys 0m0.245s
vs (w/ hot index cache):
$ time $g -q --batch -iex "set index-cache enabled on" $g -ex "start"
Setting up the environment for debugging gdb.
Breakpoint 1 at 0xa364b4: file /home/pedro/gdb/binutils-gdb/src/gdbsupport/errors.cc, line 51.
Breakpoint 2 at 0x260fa3: file /home/pedro/gdb/binutils-gdb/src/gdb/cli/cli-cmds.c, line 217.
Temporary breakpoint 3 at 0xeb06c: file /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c, line 25.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 3, main (argc=1, argv=0x7fffffffdc48) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:25
25 {
real 0m1.431s
user 0m2.395s
sys 0m0.091s
More information about the Gdb-patches
mailing list