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

[Tom Tromey]

>>>>> "Luis" == Luis Machado <luis.machado@linaro.org> writes:

>> "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.

Luis> Out of curiosity, what use cases would this cover? I imagine symbol
Luis> data could be shared, with a few exceptions, only with binaries that
Luis> are equal to the one we've already loaded/we're already debugging.

Luis> Is this a common scenario?

I think it's uncommon right now, because multi-inferior debugging is
uncommon in general.

For multi-inferior debugging, I guess it would be more common for this
reuse to happen for shared libraries than for executables.

For instance, when debugging Firefox, most of the symbols are in one
giant shared library, libxul.  It is loaded once by the launcher, which
then execs and the new inferior loads it again.  (This case, I think,
still isn't handled -- there's no mechanism for preserving the BFD
across an exec yet.)  And then, Firefox is now multi-process, and each
such process also loads libxul.  So here at least, it would be a big
improvement.

> Would type-sharing also be a common scenario?

IMO the ideal would be for all symbols and types to be
objfile-independent.  The data does not inherently need to be
objfile-dependent, it is just an accident of history, where some earlier
programmer decided to bake the objfile offsets into symbol addresses.

We've made this transformation (to remove the offset from the
representation) for minimal and partial symbols, but for full symbols it
is just a lot harder to untangle everything.

Types, maybe surprisingly, fall into this because types can link to
symbols (see cplus_struct_type::template_arguments).

Tom