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).