This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 15-02-2020 17:54, 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.

I would like to take a look at this.

Is this tromey/t/reorganize-dwarf-code-sharing on your github?

Thanks,
- Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]