From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: Richard Bunt <Richard.Bunt@arm.com>,
Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCH 3/7] gdb/fortran: Include module variables in 'info variables' output
Date: Sat, 27 Jul 2019 16:22:00 -0000 [thread overview]
Message-ID: <2105892b16a74d81bbca277b480b0d6ba61595a8.1564243858.git.andrew.burgess@embecosm.com> (raw)
In-Reply-To: <cover.1564243858.git.andrew.burgess@embecosm.com>
In-Reply-To: <cover.1564243858.git.andrew.burgess@embecosm.com>
Due to a work around in dwarf2read.c for gFortran issue #40040,
non-constant module variables don't show up in 'info variables'
output.
The reason is that issue #40040 means that the debug symbol definition
for these module variables can sometimes have the incorrect location
information attached to it. The work around in GDB is to ignore the
location information from the debug information, and mark these
symbols as LOC_UNRESOLVED, GDB will then fall back to using the
non-debug symbols in order to figure out the location of these
symbols.
The problem with this is that GDB uses LOC_UNRESOLVED to indicate a
variable declaration, and doesn't include such symbols in its output.
In an earlier commit I extended each symbol to now explicitly track if
it is marked as a declaration in the DWARF, so GDB can now use this
information rather than LOC_UNRESOLVED to exclude declarations from
the 'info variables' output.
You might think that we could just switch from checking:
SYMBOL_CLASS (sym) != LOC_UNRESOLVED
to checking:
!SYMBOL_IS_DECLARATION (sym)
However, this is not good enough, often in C or C++ the declaration is
_also_ the definition, in which case the symbol will be marked as a
declaration, but will _not_ be of address class LOC_UNRESOLVED. The
correct condition then is that we shouldn't show declarations that are
of class LOC_UNRESOLVED. The preserves the existing C/C++ behaviour
in every case I've tried so far, and also fixes the gFortran issues
that I was seeing.
gdb/ChangeLog:
* dwarf2read.c (new_symbol): Mark symbol as declaration when
appropriate.
* symtab.h (struct symbol): Add 'is_declaration' flag.
(SYMBOL_IS_DECLARATION): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/module.exp: Extend with 'info variables' test.
---
gdb/symtab.c | 3 ++-
gdb/testsuite/ChangeLog | 4 ++++
gdb/testsuite/gdb.fortran/module.exp | 24 ++++++++++++++++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/gdb/symtab.c b/gdb/symtab.c
index 1925edeeaa3..84038d15dff 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -4520,8 +4520,9 @@ search_symbols (const char *regexp, enum search_domain kind,
|| preg->exec (SYMBOL_NATURAL_NAME (sym), 0,
NULL, 0) == 0)
&& ((kind == VARIABLES_DOMAIN
+ && !(SYMBOL_CLASS (sym) == LOC_UNRESOLVED
+ && SYMBOL_IS_DECLARATION (sym))
&& SYMBOL_CLASS (sym) != LOC_TYPEDEF
- && SYMBOL_CLASS (sym) != LOC_UNRESOLVED
&& SYMBOL_CLASS (sym) != LOC_BLOCK
/* LOC_CONST can be used for more than
just enums, e.g., c++ static const
diff --git a/gdb/testsuite/gdb.fortran/module.exp b/gdb/testsuite/gdb.fortran/module.exp
index 4d71e7efac5..276f7dc3c24 100644
--- a/gdb/testsuite/gdb.fortran/module.exp
+++ b/gdb/testsuite/gdb.fortran/module.exp
@@ -13,6 +13,8 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
+load_lib "fortran.exp"
+
standard_testfile .f90
if { [prepare_for_testing "failed to prepare" $testfile $srcfile {debug f90}] } {
@@ -32,6 +34,28 @@ if ![runto MAIN__] then {
continue
}
+set int_type [fortran_int4]
+
+# Test 'info variables' can find module variables.
+gdb_test "info variables -n" \
+ [multi_line \
+ "All defined variables:" \
+ "" \
+ "File .*$srcfile:" \
+ "18:\[ \t\]+${int_type} mod1::var_const;" \
+ "17:\[ \t\]+${int_type} mod1::var_i;" \
+ "23:\[ \t\]+${int_type} mod2::var_i;" \
+ "28:\[ \t\]+${int_type} mod3::mod1;" \
+ "27:\[ \t\]+${int_type} mod3::mod2;" \
+ "29:\[ \t\]+${int_type} mod3::var_i;" \
+ "33:\[ \t\]+${int_type} modmany::var_a;" \
+ "33:\[ \t\]+${int_type} modmany::var_b;" \
+ "33:\[ \t\]+${int_type} modmany::var_c;" \
+ "33:\[ \t\]+${int_type} modmany::var_i;" \
+ "37:\[ \t\]+${int_type} moduse::var_x;" \
+ "37:\[ \t\]+${int_type} moduse::var_y;" ]
+
+
# Do not use simple single-letter names as GDB would pick up for expectedly
# nonexisting symbols some static variables from system libraries debuginfos.
--
2.14.5
next prev parent reply other threads:[~2019-07-27 16:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-27 16:22 [PATCH 0/7] Fortran info types, info modules, info module Andrew Burgess
2019-07-27 16:22 ` Andrew Burgess [this message]
2019-07-27 16:22 ` [PATCH 2/7] gdb: Add an is_declaration field to each symbol Andrew Burgess
2019-07-29 20:21 ` Tom Tromey
2019-07-30 21:00 ` Andrew Burgess
2019-07-27 16:23 ` [PATCH 4/7] gdb/fortran: Implement la_print_typedef for Fortran Andrew Burgess
2019-08-28 12:37 ` Andrew Burgess
2019-07-27 16:23 ` [PATCH 7/7] gdb: Add new commands to list module variables and functions Andrew Burgess
2019-07-27 17:06 ` Eli Zaretskii
2019-07-27 16:23 ` [PATCH 1/7] gdb: Add new -n flag to some info commands Andrew Burgess
2019-07-27 16:41 ` Eli Zaretskii
2019-07-30 21:02 ` Andrew Burgess
2019-07-31 14:51 ` Eli Zaretskii
2019-08-26 15:52 ` Andrew Burgess
2019-08-26 16:19 ` Eli Zaretskii
2019-08-27 15:27 ` Andrew Burgess
2019-08-28 15:13 ` [committed][gdb/testsuite] Fix info-var.exp for debug info from other files Tom de Vries
2019-07-29 20:23 ` [PATCH 1/7] gdb: Add new -n flag to some info commands Tom Tromey
2019-07-27 16:23 ` [PATCH 6/7] gdb/fortran: Add new 'info modules' command Andrew Burgess
2019-07-27 16:45 ` Eli Zaretskii
2019-07-29 20:30 ` Tom Tromey
2019-07-27 16:23 ` [PATCH 5/7] gdb/fortran: Don't include module symbols when searching for types Andrew Burgess
2019-08-28 12:37 ` Andrew Burgess
2019-08-29 9:09 ` Tom de Vries
2019-08-29 11:45 ` Tom de Vries
2019-08-29 12:47 ` [committed][gdb/testsuite] Fix gdb.fortran/info-types.exp regexp Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2105892b16a74d81bbca277b480b0d6ba61595a8.1564243858.git.andrew.burgess@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=Richard.Bunt@arm.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox