Bug 31363

Summary: Remove support for .gdb_index
Product: gdb Reporter: Tom Tromey <tromey>
Component: symtabAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: fche, mark, sam
Priority: P2    
Version: HEAD   
Target Milestone: ---   
See Also: https://sourceware.org/bugzilla/show_bug.cgi?id=32504
https://sourceware.org/bugzilla/show_bug.cgi?id=32513
https://sourceware.org/bugzilla/show_bug.cgi?id=30838
https://sourceware.org/bugzilla/show_bug.cgi?id=27930
Host: Target:
Build: Last reconfirmed:
Project(s) to access: ssh public key:
Bug Depends on: 23504, 31132    
Bug Blocks:    

Description Tom Tromey 2024-02-09 20:03:48 UTC
Now that the .debug_names writer has been rewritten,
I think we should plan to remove .gdb_index.

While .debug_names has some drawbacks (reuse of the
string table means more data to download when just
the index is desired), it is also better documented
and integrates better with the new DWARF scanner.
Comment 1 Frank Ch. Eigler 2024-02-10 21:04:26 UTC
What about preexisting binaries that have .gdb_index built into them but no .debug_names?
Comment 2 Tom Tromey 2024-02-10 21:48:49 UTC
(In reply to Frank Ch. Eigler from comment #1)
> What about preexisting binaries that have .gdb_index built into them but no
> .debug_names?

We don't have to delete the reader immediately.

Worth noting here that .gdb_index won't easily work with lazy CU
expansion, if we end up implementing that.
Comment 3 Frank Ch. Eigler 2025-01-03 20:22:54 UTC
Could you refresh my memory (so to speak) about how a current day linux distro user is to create binaries with .debug_names sections?  I see "gcc -gdwarf-5 -gpubnames" creating .debug_pubnames.  Is gdb-add-index -dwarf-5 still necessary?
Comment 4 Mark Wielaard 2025-01-03 20:58:43 UTC
Note that the .debug_pubnames and .debug_pubtypes are DWARF4 lookup tables. And are replaced by .debug_names in DWARF5. gdb-add-index generates .gdb_index and gdb-add-index -dwarf-5 generates .debug_names.
Comment 5 Tom Tromey 2025-01-04 17:52:40 UTC
(In reply to Frank Ch. Eigler from comment #3)
> Could you refresh my memory (so to speak) about how a current day linux
> distro user is to create binaries with .debug_names sections?  I see "gcc
> -gdwarf-5 -gpubnames" creating .debug_pubnames.  Is gdb-add-index -dwarf-5
> still necessary?

You have to use gdb to make the index.
gdb works around some bugs in the DWARF standard and
also IIRC adds some extra info that it needs to use
.debug_names well.
You don't need any special compiler flags.
Comment 6 Mark Wielaard 2025-01-05 12:39:05 UTC
(In reply to Tom Tromey from comment #0)
> Now that the .debug_names writer has been rewritten,
> I think we should plan to remove .gdb_index.

Since which version of gdb does the .debug_names writing in gdb-add-index work correctly and since which version of gdb does it correctly interpret .debug_names?

Asking to know when/if we want to switch to gdb-add-index -dwarf-5 for debugedit find-debug-info. See https://sourceware.org/bugzilla/show_bug.cgi?id=32513
Comment 7 Tom Tromey 2025-01-05 18:17:56 UTC
(In reply to Mark Wielaard from comment #6)
> (In reply to Tom Tromey from comment #0)
> > Now that the .debug_names writer has been rewritten,
> > I think we should plan to remove .gdb_index.
> 
> Since which version of gdb does the .debug_names writing in gdb-add-index
> work correctly and since which version of gdb does it correctly interpret
> .debug_names?

I didn't update NEWS, it seems, but according to bug#24820,
the fix is in gdb 15.

> Asking to know when/if we want to switch to gdb-add-index -dwarf-5 for
> debugedit find-debug-info. See
> https://sourceware.org/bugzilla/show_bug.cgi?id=32513

Note it won't create .debug_aranges yet.  So without this it isn't
always useful.
Comment 8 Tom Tromey 2025-01-05 18:18:44 UTC
See bug#31132 for the aranges thing.
Comment 9 Tom Tromey 2025-02-11 14:23:55 UTC
Working on bug#16698 showed me that in some cases the
gdb index doesn't really work.  For instance it doesn't
seem to correctly implement the "paramless.exp" change.
It also uses a heuristic for name splitting (since the
language isn't available).

I'm more convinced now that it should be deprecated & removed.