mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-22 19:09:31 +08:00
16b0db75af
When running test-case gdb.base/c-linkage-name.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, I run into:
...
PASS: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no
FAIL: gdb.base/c-linkage-name.exp: print symada__cS before partial symtab \
expansion
...
The test-case tries to print a symbol before and after symtab expansion.
And it tries to ensure (since commit 13c3a74afb) that the symtab containing
the symbol is not yet expanded when doing the 'before' print, by placing the
symbol in a different CU (c-linkage-name-2.c) from the one containing main
(c-linkage-name.c), such that when we load the exec and expand the symtab
containing main, the symtab containing the symbol isn't.
The generated debug info for the test-case when using mentioned target board
however is structured like this:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : <artificial>
<1><f4>: Abbrev Number: 2 (DW_TAG_imported_unit)
<f5> DW_AT_import : <0x16b> [Abbrev Number: 1]
<1><f9>: Abbrev Number: 2 (DW_TAG_imported_unit)
<fa> DW_AT_import : <0x19c> [Abbrev Number: 1]
<1><fe>: Abbrev Number: 3 (DW_TAG_subprogram)
<ff> DW_AT_abstract_origin: <0x17d>
<1><115>: Abbrev Number: 4 (DW_TAG_variable)
<116> DW_AT_abstract_origin: <0x1ce>
<0><16b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<171> DW_AT_name : c-linkage-name.c
<1><17d>: Abbrev Number: 2 (DW_TAG_subprogram)
<17e> DW_AT_name : main
<0><19c>: Abbrev Number: 1 (DW_TAG_compile_unit)
<1a2> DW_AT_name : c-linkage-name-2.c
<1><1ce>: Abbrev Number: 5 (DW_TAG_variable)
<1cf> DW_AT_name : mundane
<1d6> DW_AT_linkage_name: symada__cS
...
So, the CU named <artificial> contains both the concrete main and the concrete
symbol, which explains the FAIL.
The first test should fail, but passes for two reasons.
First of all, due to PR symtab/25700, we have two regular partial symtabs
c-linkage-name-2.c instead of one, and one of them is expanded, the other one
not:
...
{ psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38d6f60)
readin yes
{ psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38d6fe0)
readin no
...
And then there's the include symtab, which is also not expanded:
...
{ psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38143e0)
readin no
...
Fix the FAIL by explicitly setting the language before load, changing the
language setting from auto/c to manual/c, such that the symtab containing main
is no longer expanded.
And make the symtab expansion testing more robust by using the output of
"maint info symtabs" instead of "maint info psymtabs".
Tested on x86_64-linux, using native and target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp, readnow.exp and
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects.
gdb/testsuite/ChangeLog:
2020-03-31 Tom de Vries <tdevries@suse.de>
* gdb.base/c-linkage-name.exp: Fix test-case comment. Set language to
c. Use "maint info symtabs" to check symtab expansion.
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.