96c7f87394
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.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| COPYING | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| ChangeLog | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| README | ||
| README-maintainer-mode | ||
| ar-lib | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| lt~obsolete.m4 | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.