Re: [RFA 08/15] Remove readin and compunit_symtab fields from psymtab

[Tom Tromey <tom@tromey.com>]

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

>> In order to move psymtabs off of the objfile obstack, there must be no
>> backlinks from the psymtab (or associated objects) to anything
>> allocated on the objfile obstack.

>> This patch removes the readin and compunit_symtab fields from psymtab
>> to help achieve this goal, replacing them with per-objfile maps
>> indicating which psymtabs have been read in.  This split will allow
>> for psymtab reuse across objfiles in the future.

Simon> This LGTM, but I have two question.  In the future, is the intent to also
Simon> make symtabs (compunit_symtab) independent from program spaces, and
Simon> shareable across objfiles, or would that not be possible?  If it is
Simon> possible, would the compunit_symtab pointer in psymtab re-appear, since
Simon> there would now again be a single compunit_symtab for each psymtab?

I think it is a good long-term goal, but not the only possible one in
this area.

The main downside is that it is hard to do.  There's a reasonably
complete to-do list here:

    https://sourceware.org/gdb/wiki/ObjfileSplitting

Some of these steps are tricky and/or laborious.

So, my thought with this second series was that perhaps gdb could get
most of the benefits of the split without the full implementation.

To my mind the performance issue is the major one to solve, with memory
use being second.  So, for instance, if gdb had this psymbol series,
plus maybe incremental expansion of partial symbol tables, perhaps that
would be enough.  This is based in my belief that psymtab reading is the
obvious spot where gdb spends its time, and that CU expansion is
generally fast (but with the occasional counterexample).

So maybe the full objfile splitting project will not even happen (and so
the backlink would never be restored).

Simon> As Pedro pointed out a few times, unordered_map is an hash map with open
Simon> hashing.  So we change what was previously a single pointer dereference
Simon> to a lookup in a hash table, followed with a linear search in a linked
Simon> list.  If this map is looked up very frequently, maybe we should consider
Simon> using an htab_t instead?  Some profiling data would help, but it seems
Simon> like psymtab_read_in_p is called quite a bit when looking up symbols...

I will look into it a bit.

Tom