Re: [PATCH v2] gdb/dwarf2: Add symbols for function declarations

[Kevin Buettner <kevinb@redhat.com>]

On Fri, 05 Sep 2025 09:38:13 -0600
Tom Tromey <tom@tromey.com> wrote:

> >>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:  
> 
> Kevin>   This version 2 commit
> Kevin> adds that by making DW_TAG_subprogram declarations "interesting" to
> Kevin> the indexer.  The changes which do this are in gdb/dwarf2/abbrev.c
> Kevin> and gdb/dwarf2/cooked-indexer.c.  
> 
> I have some questions about this change.
> 
> How many symbols does it add, and what performance impact does it have?
> I tend to think the indexer is fast primarily because it skips DIEs, but
> IIUC this will have it read many more.
> 
> Do these declaration symbols end up in .debug_names and .gdb_index?  I
> suspect they should not.  (Particularly for .debug_names which
> specifically excludes them in the text of the standard.)
> 
> Does "break" on such a symbol result in many more CU expansions?  If so
> then I think this is a problem, because a declaration by its nature is
> not useful for breakpoints.

I'm still gathering data and I'm trying to make sense of some of the
data already gathered, so I'm not quite ready to dive into too many
details yet.

However, using Simon's methodology, I've tested on 4 different x86_64
machines.  On those machines, the total wall clock time increased from
between 6.9 to 9.2 percent, depending on machine.  However, on my
(aarch64) macbook, the wall clock time increased by 267% !!  I need to
understand why the macbook took so much longer...

This patch is of most value when library symbols are unavailable.  So it
may make sense for there to be a setting to enable or disable loading
of declarations.  An "auto" mode could, perhaps, cause loading of
declarations to be disabled when loading system libraries, but be
enabled for user libraries and the executable.  And, even for the
latter category, GDB could check to see if (say) the C library has
symbols.  If it does, then it could be disabled.

> What does "print malloc" say with this patch in place?

Without my patch:

(gdb) p malloc
$1 = {<text variable, no debug info>} 0x7ffff7d2fb10 <malloc>

With my patch:

(gdb) p malloc
$1 = {void *(unsigned long)} 0x7ffff7d2fb10 <malloc>

These were both run on the same machine, which does not have glibc
debuginfo installed, nor was debuginfod allowed to provide any
symbols.