public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/25695] New: abstract and concrete variable listed both with "info locals"
@ 2020-03-18 22:46 vries at gcc dot gnu.org
2020-03-18 22:46 ` [Bug symtab/25695] " vries at gcc dot gnu.org
2021-04-14 16:57 ` cvs-commit at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: vries at gcc dot gnu.org @ 2020-03-18 22:46 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=25695
Bug ID: 25695
Summary: abstract and concrete variable listed both with "info
locals"
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: symtab
Assignee: unassigned at sourceware dot org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
There's an open issue described in
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=41bd68f52c05f5654bed49f312f6562c8d048897
:
...
Show optimized out local variables in "info locals"
Currently, optimized out variables are not shown when doing "info
locals". Some users found that confusing, thinking GDB forgot to print
their variable. This patch adds them to the "info locals" output. I
added a test in gdb.dwarf2 to test for that behavior. I think doing a
synthetic DWARF test is the easiest way to have an optimized out local
variable for sure.
However, this change reveals what I think is a bug in GDB, see:
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2017-September/004394.html
This patch marks the tests in inline-locals.exp that start failing as
KFAIL. I'd like to tackle this bug eventually, but I don't have the
time right now. I think it's still better to show an extra erroneous
entry than to not show the optimized out variables at all. I haven't
created a bug in bugzilla yet, but if we agree it's indeed a bug, I'll
create one and update the setup_kfail lines with the actual bug number
before pushing.
...
The KFAILs have been like this:
...
setup_kfail "gdb/xyz" *-*-*
...
for more than two years now.
Let's have this PR in bugzilla at least to keep track of the KFAIls.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug symtab/25695] abstract and concrete variable listed both with "info locals"
2020-03-18 22:46 [Bug symtab/25695] New: abstract and concrete variable listed both with "info locals" vries at gcc dot gnu.org
@ 2020-03-18 22:46 ` vries at gcc dot gnu.org
2021-04-14 16:57 ` cvs-commit at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: vries at gcc dot gnu.org @ 2020-03-18 22:46 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=25695
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |simark at simark dot ca
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug symtab/25695] abstract and concrete variable listed both with "info locals"
2020-03-18 22:46 [Bug symtab/25695] New: abstract and concrete variable listed both with "info locals" vries at gcc dot gnu.org
2020-03-18 22:46 ` [Bug symtab/25695] " vries at gcc dot gnu.org
@ 2021-04-14 16:57 ` cvs-commit at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-14 16:57 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=25695
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tankut Baris Aktemur
<aktemur@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=34dc0f95968f835d4c4ac01373de63dec2902c70
commit 34dc0f95968f835d4c4ac01373de63dec2902c70
Author: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Date: Mon Feb 8 16:48:39 2021 +0100
gdb/dwarf2: fix "info locals" for clang-compiled inlined functions
GDB reports duplicate local vars with "<optimized out>" values for
inlined functions that are compiled with Clang.
Suppose we have
__attribute__((always_inline))
static void aFunction() {
int a = 42;
if(a > 2) {
int value = a;
value += 10; /* break here */
}
}
The "info locals" command at the "break here" line gives the following
output:
...
Breakpoint 1, aFunction () at test.c:6
6 value += 10; /* break here */
(gdb) info locals
value = 42
a = 42
value = <optimized out>
(gdb)
The reason is, inlined functions that are compiled by Clang do not
contain DW_AT_abstract_origin attributes in the DW_TAG_lexical_block
entries. See
https://bugs.llvm.org/show_bug.cgi?id=49953
E.g. the DIE of the inlined function above is
0x00000087: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x0000002a "aFunction")
DW_AT_low_pc (0x00000000004004b2)
DW_AT_high_pc (0x00000000004004d2)
DW_AT_call_file ("/tmp/test.c")
DW_AT_call_line (11)
DW_AT_call_column (0x03)
0x0000009b: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -4)
DW_AT_abstract_origin (0x00000032 "a")
0x000000a3: DW_TAG_lexical_block
DW_AT_low_pc (0x00000000004004c3)
DW_AT_high_pc (0x00000000004004d2)
0x000000b0: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -8)
DW_AT_abstract_origin (0x0000003e "value")
This causes GDB to fail matching the concrete lexical scope with the
corresponding abstract entry. Hence, the local vars of the abstract
function that are contained in the lexical scope are read separately
(and thus, in addition to) the local vars of the concrete scope.
Because the abstract definitions of the vars do not contain location
information, we see the extra 'value = <optimized out>' above.
This bug is highly related to PR gdb/25695, but the root cause is not
exactly the same. In PR gdb/25695, GCC emits an extra
DW_TAG_lexical_block without an DW_AT_abstract_origin that wraps the
body of the inlined function. That is, the trees of the abstract DIE
for the function and its concrete instance are structurally not the
same. In the case of using Clang, the trees have the same structure.
To tackle the Clang case, when traversing the children of the concrete
instance root, keep a reference to the child of the abstract DIE that
corresponds to the concrete child, so that we can match the two DIEs
heuristically in case of missing DW_AT_abstract_origin attributes.
The updated gdb.opt/inline-locals.exp test has been checked with GCC
5-10 and Clang 5-11.
gdb/ChangeLog:
2021-04-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* dwarf2/read.c (inherit_abstract_dies): Keep a reference to the
corresponding child of the abstract DIE when iterating the
children of the concrete DIE.
gdb/testsuite/ChangeLog:
2021-04-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.opt/inline-locals.c (scoped): New function.
(main): Call 'scoped'.
* gdb.opt/inline-locals.exp: Update with "info locals" tests
for scoped variables.
* gdb.dwarf2/dw2-inline-with-lexical-scope.c: New file.
* gdb.dwarf2/dw2-inline-with-lexical-scope.exp: New file.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-04-14 16:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-18 22:46 [Bug symtab/25695] New: abstract and concrete variable listed both with "info locals" vries at gcc dot gnu.org
2020-03-18 22:46 ` [Bug symtab/25695] " vries at gcc dot gnu.org
2021-04-14 16:57 ` cvs-commit at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).