[RFC] Proposal for a new DWARF name index section

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> * I do not find the symbols reading much slow myself (working _on_
Jan> small GDB).

Jan> * People complaining it is slow usually use IDEs which use rather file:line
Jan>   based breakpoints, don't they?  (As it was discussed on RH IRC today.)
Jan>   = Assuming the C++ people do not put breakpoints on static out-of-scope
Jan>     functions by name.

Thanks for bringing this up.  I think there are a few different use
cases to consider.

My reason for adding "break function" to list is just that it is such a
common CLI operation.

This current proposal is a way to fix the index problem, which is one
necessary step.  It is not the only necessary step, though -- we must
also change gdb to take advantage of the index.  This probably means
some kind of surgery on partial symbol tables (ideally I'd like to get
rid of them, but we'll see).

Jan> We have concluded the currently missing information is for:
Jan> * static functions (are they really needed for the file:line IDE usecases?)
Jan> * inlined functions which have no concrete out-of-line instance
Jan>   (the same file:line IDE usecase question)

Jan> IMO not for:
Jan> * static non-function symbols are deprecated (backward GDB
Jan> compatibility only)

Ok.  This is where I disagree, for reasons I won't repeat :)

Jan> * Fallback to the full read-in only for:
Jan>   * static functions in out of the language (compiler) scope
Jan>   * inlined functions which have no concrete out-of-line instance
Jan>   * reference to a non-existing symbol

This is another thing I don't like.  It means that a typo in a "break"
command will cause gdb to pause while it scans a lot of debuginfo.  This
also means that any attempt to set a pending breakpoint will require a
full scan.

Jan> As a summary GDB could already give (with proper non-existing
Jan> patches) in the common usecases acceptable performance even based
Jan> just on the existing DWARF indexes, couldn't it?  I did not think
Jan> so before this mail thread.

It could do better than it does today, but still not as good as we could
do with a few extensions.  The extensions are cheap on the gcc side
(already done IIUC) and because there is no gdb patch yet, equally cheap
there.

Tom