[gdb/symtab] Fix partial unit psymtabs

Consider test-case gdb.dwarf2/imported-unit.exp.

It contains a CU with type int:
...
 <0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <12a>   DW_AT_language    : 4       (C++)
    <12b>   DW_AT_name        : imported_unit.c
 <1><13b>: Abbrev Number: 3 (DW_TAG_base_type)
    <13c>   DW_AT_byte_size   : 4
    <13d>   DW_AT_encoding    : 5       (signed)
    <13e>   DW_AT_name        : int
...
which is imported in another CU:
...
 <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <d3>   DW_AT_language    : 4        (C++)
    <d4>   DW_AT_name        : <artificial>
 <1><e1>: Abbrev Number: 3 (DW_TAG_imported_unit)
    <e2>   DW_AT_import      : <0x129>  [Abbrev Number: 2]
...

However, if we print the partial symbols:
...
$ gdb -batch imported-unit  -ex "maint print psymbols"
...
we see type int both in the importing CU:
...
Partial symtab for source file <artificial>@0xc7 (object 0x29f9b80)
  ...
  Depends on 1 other partial symtabs.
    0 0x2a24240 imported_unit.c
  Global partial symbols:
    `main', function, 0x4004b2
  Static partial symbols:
    `int', type, 0x0
...
and in the imported CU:
...
Partial symtab for source file imported_unit.c (object 0x2a24240)
  ...
  Depends on 0 other partial symtabs.
  Shared partial symtab with user 0x29f9b80
  Static partial symbols:
    `int', type, 0x0
...

This is an artefact resulting from the fact that all CUs in an objfile
share the same storage array for static partial symbols (and another array for
global partial symbols), using a range to describe their symbols.

Then when scanning the partial symbols of a CU and encountering an import, either:
- the referred CU has not been parsed yet, and will be parsed, and the range of
  static partial symbols of the referred CU will be a subrange of the range of
  static partial symbols of this CU, or
- the referred CU has already been parsed, and the range of static partial
  symbols of the referred CU will not be a subrange of the range of static
  partial symbols of this CU.

This is inconsistent handling, and confuses the notion of a symbol belonging to
a single symtab.

Furthermore, it might slow down searches, given that the symbol needs to be
skipped twice.

Finally, the same issue holds for global partial symbols, where the range of a
CU is sorted after parsing is finished.  Obviously sorting the range of a CU
may invalidate subranges, effectively moving symbols in and out of imported
CUs.

Fix this for both static and global partial symbols, by gathering partial
symbols in a per-CU vector, and adding those symbols to the per-objfile
storage only once complete.

Tested on x86_64-linux, with native and board cc-with-dwz and cc-with-dwz-m.

gdb/ChangeLog:

2020-03-13  Tom de Vries  <tdevries@suse.de>

	PR symtab/25646
	* psymtab.c (partial_symtab::partial_symtab): Don't set
	globals_offset and statics_offset.  Push element onto
	current_global_psymbols and current_static_psymbols stacks.
	(concat): New function.
	(end_psymtab_common): Set globals_offset and statics_offset.  Pop
	element from current_global_psymbols and current_static_psymbols
	stacks.  Concat popped elements to global_psymbols and
	static_symbols.
	(add_psymbol_to_list): Use current_global_psymbols and
	current_static_psymbols stacks.
	* psymtab.h (class psymtab_storage): Add current_global_psymbols and
	current_static_psymbols fields.

gdb/testsuite/ChangeLog:

2020-03-13  Tom de Vries  <tdevries@suse.de>

	PR symtab/25646
	* gdb.dwarf2/imported-unit.exp: Add test.

1 files changed, 6 insertions, 0 deletions

diff --git a/gdb/psymtab.h b/gdb/psymtab.h
index 040b973..e8bafbe 100644
--- a/gdb/psymtab.h
+++ b/gdb/psymtab.h
@@ -129,6 +129,12 @@ public:
   std::vector<partial_symbol *> global_psymbols;
   std::vector<partial_symbol *> static_psymbols;
 
+  /* Stack of vectors of partial symbols, using during psymtab
+     initialization.  */
+
+  std::vector<std::vector<partial_symbol *>*> current_global_psymbols;
+  std::vector<std::vector<partial_symbol *>*> current_static_psymbols;
+
 private:
 
   /* The obstack where allocations are made.  This is lazily allocated