Re: [PATCH 00/14] Share DWARF partial symtabs between objfiles

Simon Marchi
2020-02-23T02:37:10Z

On 2020-02-15 11:54 a.m., Tom Tromey wrote:
> A long-term goal for multi-inferior debugging has been to "split" an
> objfile, so that the bulk of the data can be shared across inferiors.
> Although a lot of progress has been made on this front, it has turned
> out to be surprisingly difficult to fully implement.
>
> "Recently" (a year or two ago) I realized that we could get most of
> the benefits of this split by sharing partial symbol tables. This is
> true because reading partial symbols is the slowest operation that
> users see -- in most cases, expanding a full symtab is reasonably
> quick.
>
> Implementing this also turned out to be tricky; but unlike the
> situation with types and symbols, it was possible to do incrementally.
>
> This series implements this idea for DWARF. It separates
> dwarf2_per_objfile into shareable and unshareable parts; then, when
> possible, the object is attached to the BFD.
>
> You can see the difference when timing "add-inferior -exec ./gdb",
> after "gdb ./gdb":
>
> Before: Command execution time: 1.667661 (cpu), 1.687607 (wall)
> After : Command execution time: 0.150011 (cpu), 0.151292 (wall)
>
> In this series I did not rename dwarf2_per_objfile. I'd prefer to do
> this after landing this series; it seemed like a large, mostly
> cosmetic, and yet hard-to-rebase patch. Also, I wanted to consult
> with everyone else about what we ought to call it.
>
> I also didn't attempt to implement this sharing for CTF. I don't
> really know much about CTF; but it seems like it ought to be possible.
> (Though I wonder if CTF wouldn't benefit more from simply bypassing
> partial symbols entirely.)
>
> Regression tested on x86-64 Fedora 28. I also did various tests by
> hand, and tested it by hand, under valgrind, on a gdb built with
> -fdebug-types-section.
>
> Like I mentioned earlier, this is a tricky series, so it would benefit
> from careful review. The main danger is that, if I missed a spot, we
> could end up in a situation where gdb will crash in a multi-inferior
> scenario.
>
> Tom

I've started to look at this, and this is my initial feeling (as discussed
with Tom on IRC).

This patch series implements:

objfile -> dwarf2 object shared between objfiles -> dwarf2 objfile-specific object

With the last pointer getting updated at each entry point of the DWARF code to point
to the right "dwarf2 objfile-specific object" according to the context.

I think it would be more natural and easier to understand to have :

objfile -> dwarf2 objfile-specific object -> dwarf2 object shared between objfiles

Many "dwarf2 objfile-specific" objects would point to one "dwarf2 object shared between
objfiles", without special tricks. Of course, it's much easier said than done.

I'd like to know: did you consider this way of doing it and chose not to do it
because of the complexity / size of the change? Is the current patchset a stepping
stone towards it?

Simon