Re: [RFC][gdb/symtab] Lazy expansion of full symbol table

[Tom de Vries <tdevries@suse.de>]

On 6/20/21 8:17 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> I found out that the precondition for using std::lower_bound of the
> Tom> vector being sorted in a certain way is not valid:
> [...]
> 
> While debugging a different failure today, I found that the 'find'
> method wasn't waiting for the future to resolve, so it was allowing use
> of the vector before it was ready.  This is fixed on the branch now.
> 
> I have 125 regressions to go.

I did a build and reg-test with the current state of branch, and the two
patches I've mentioned.

I get:
...
$ grep -c ^FAIL: gdb.sum
218
$ grep -c ^ERROR: gdb.sum
193
...

Possibly more fails because of using
--with-separate-debug-dir=/usr/lib/debug ? Just to give you another data
point, not sure if this is terribly relevant.

I also did a speed test with my running example of branch tip vs merge
base, and got:
...
$ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1
maxmem: 348472
real: 0.50
user: 1.09
system: 0.09
$ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1
maxmem: 509212
real: 2.58
user: 2.53
system: 0.09
...
which is a nice factor 5 speedup, or 2 seconds in absolute terms.

However, when I do also set the breakpoint:
...
$ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1
-ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 1011140
real: 5.09
user: 5.54
system: 0.24
$ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1
-ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 873952
real: 5.55
user: 5.37
system: 0.24
...
I'm left with just 0.5 seconds speedup.

I investigated whether that was caused by more CUs being expanded, but
that doesn't seem to be the case.

So I'm tentatively drawing the conclusion that it makes sense for me to
continue on the lazy expansion effort.

Thanks,
- Tom

> At the same time I think part of the
> quick function code still has to be rewritten; I haven't tested DWO yet;
> and I am not sure all the modes that Ada supports are handled by the
> lookup code.  So there's still a reasonable amount to do.  Then of
> course there's the final rebasing to shape it up, the branch history is
> particularly ugly at this moment.
> 
> Tom
>