Re: Loading some symbols, when, and index-cache

On 4/6/25 12:07 PM, Lluís Batlle i Rossell via Gdb wrote:
> Hello,
>
> I'm trying to make sense of what symbols are loaded and when, in gdb.
> For example, opening an elf file, it will build some index (usable as
> index-cache) of some symbols, but not all.
>
> If I do "gdb gdb" (for my compiled gdb), and then "maint print stat" I
> get:
>
>    Number of "minimal" symbols read: 33435
>    Number of read CUs: 0
>    Number of unread CUs: 682
>
> Why haven't all CUs been read, and incorporated into the index? Because at
> file loading the CUs symbols index is generated with worker threads (read.c),
> therefore, potentially using all cores of the system. And the result would
> be cached in the index-cache.
>
> Because the next thing I notice is that when I type "list def<TAB>" to get
> symbol completion, a very slow single-thread symbol expansion causes many CUs
> to be loaded. After which:, "maint print stat":
>
>    Number of "minimal" symbols read: 33435
>    Number of "full" symbols read: 2732412
>    Number of "types" defined: 4292812
>    Number of symbol tables: 57075
>    Number of symbol tables with line tables: 9608
>    Number of symbol tables with blockvectors: 351
>    Number of read CUs: 351
>    Number of unread CUs: 331
>
> Is there any way this work can be done ahead? Why the index-cache only helps
> for the "minimal" symbols? How can we use the cache for all symbols? Why not
> all CUs have been loaded yet?

I can't answer all questions, but I can help with two of them:

  > is there any way this work can be done ahead?

Yes! you can use the --readnow option to force gdb to read all symbols 
of the added inferior... however

  > Why not all CUs have been loaded yet?

It is super slow. Your example completion managed to avoid reading half 
of all symbols and you already felt the time, doing twice that work 
every time you start up your debug section would be very noticeable for 
little gain considering that most debug sessions won't span all the 
codebase.

To get a sense of how much of a slowdown that is, I tested locally and:

$ time ./gdb gdb --batch -ex "complete list def" #Basically the same as 
you did
./gdb gdb --batch -ex "complete list def"  42.40s user 1.19s system 120% 
cpu 36.243 total
$ time ./gdb gdb --batch --readnow -ex "complete list def"
./gdb gdb --batch --readnow -ex "complete list def"  58.32s user 1.79s 
system 100% cpu 1:00.08 total

So even with the slower expansion, GDB is still faster than if we had 
all symbols being read at the start, and this isn't even taking into 
account the memory usage.

I can't help with the cache stuff, though, never touched it.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
> Regards,
> Lluís.
>