public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/25886] New: [debug-types] FAIL: gdb.base/enumval.exp: p ZERO
@ 2020-04-28 11:53 vries at gcc dot gnu.org
  2020-04-28 12:18 ` [Bug symtab/25886] " vries at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: vries at gcc dot gnu.org @ 2020-04-28 11:53 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=25886

            Bug ID: 25886
           Summary: [debug-types] FAIL: gdb.base/enumval.exp: p ZERO
           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: ---

When running test-case gdb.base/enumval.exp with target board debug-types, we
have:
...
(gdb) p ZERO^M
No symbol "ZERO" in current context.^M
(gdb) FAIL: gdb.base/enumval.exp: p ZERO
...

Minimal reproducer:
...
$ gdb -batch outputs/gdb.base/enumval/enumval \
  -ex "p e" \
  -ex "p ZERO" 
$1 = J
No symbol "ZERO" in current context.
...

OTOH, this does work:
...
$ gdb -batch outputs/gdb.base/enumval/enumval \
  -ex "p ZERO" 
$1 = ZERO
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug symtab/25886] [debug-types] FAIL: gdb.base/enumval.exp: p ZERO
  2020-04-28 11:53 [Bug symtab/25886] New: [debug-types] FAIL: gdb.base/enumval.exp: p ZERO vries at gcc dot gnu.org
@ 2020-04-28 12:18 ` vries at gcc dot gnu.org
  2020-04-28 12:19 ` vries at gcc dot gnu.org
  2020-04-28 14:44 ` vries at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: vries at gcc dot gnu.org @ 2020-04-28 12:18 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=25886

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
The problem becomes clear in new_symbol, where we're creating the symbol, and
then hit this bit:
...
        case DW_TAG_enumerator:
          attr = dwarf2_attr (die, DW_AT_const_value, cu);
          if (attr != nullptr)
            {
              dwarf2_const_value (attr, sym, cu);
            }
          {
            /* NOTE: carlton/2003-11-10: See comment above in the               
               DW_TAG_class_type, etc. block.  */

            list_to_add
              = (cu->list_in_scope == cu->get_builder ()->get_file_symbols ()
                 && cu->language == language_cplus
                 ? cu->get_builder ()->get_global_symbols ()
                 : cu->list_in_scope);
          }
          break;
...

Because cu->list_in_scope is NULL, also list_to_add becomes NULL, and we never
add the symbol to a symtab.

The root cause for cu->list_in_scope == NULL comes from how the .debug_types
section is handled:
...
Contents of the .debug_types section:

  Compilation Unit @ offset 0x0:
   Length:        0x35 (32-bit)
   Version:       4
   Abbrev Offset: 0x64
   Pointer Size:  8
   Signature:     0x1af8140871c0d393
   Type Offset:   0x1d
 <0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
    <18>   DW_AT_language    : 12       (ANSI C99)
    <19>   DW_AT_stmt_list   : 0xe9
 <1><1d>: Abbrev Number: 2 (DW_TAG_enumeration_type)
    <1e>   DW_AT_encoding    : 7        (unsigned)
    <1f>   DW_AT_byte_size   : 4
    <20>   DW_AT_type        : <0x31>
    <24>   DW_AT_decl_file   : 1
    <25>   DW_AT_decl_line   : 20
    <26>   DW_AT_sibling     : <0x31>
 <2><2a>: Abbrev Number: 3 (DW_TAG_enumerator)
    <2b>   DW_AT_name        : (indirect string, offset: 0x208): ZERO
    <2f>   DW_AT_const_value : 0
 <2><30>: Abbrev Number: 0
 <1><31>: Abbrev Number: 4 (DW_TAG_base_type)
    <32>   DW_AT_byte_size   : 4
    <33>   DW_AT_encoding    : 7        (unsigned)
    <34>   DW_AT_name        : (indirect string, offset: 0x58): unsigned int
 <1><38>: Abbrev Number: 0
  Compilation Unit @ offset 0x39:
   Length:        0x47 (32-bit)
   Version:       4
   Abbrev Offset: 0x64
   Pointer Size:  8
   Signature:     0x42f8c3f86b4c459f
   Type Offset:   0x1d
 <0><50>: Abbrev Number: 1 (DW_TAG_type_unit)
    <51>   DW_AT_language    : 12       (ANSI C99)
    <52>   DW_AT_stmt_list   : 0xe9
 <1><56>: Abbrev Number: 5 (DW_TAG_enumeration_type)
    <57>   DW_AT_name        : e
    <59>   DW_AT_encoding    : 7        (unsigned)
    <5a>   DW_AT_byte_size   : 8
    <5b>   DW_AT_type        : <0x7c>
    <5f>   DW_AT_decl_file   : 1
    <60>   DW_AT_decl_line   : 18
    <61>   DW_AT_sibling     : <0x7c>
 <2><65>: Abbrev Number: 6 (DW_TAG_enumerator)
    <66>   DW_AT_name        : I
    <68>   DW_AT_const_value : 0
 <2><69>: Abbrev Number: 7 (DW_TAG_enumerator)
    <6a>   DW_AT_name        : J
    <6c>   DW_AT_const_value : 0xffffffff
 <2><70>: Abbrev Number: 8 (DW_TAG_enumerator)
    <71>   DW_AT_name        : K
    <73>   DW_AT_const_value : 0xf000000000000000
 <2><7b>: Abbrev Number: 0
 <1><7c>: Abbrev Number: 4 (DW_TAG_base_type)
    <7d>   DW_AT_byte_size   : 8
    <7e>   DW_AT_encoding    : 7        (unsigned)
    <7f>   DW_AT_name        : (indirect string, offset: 0x53): long unsigned
int
 <1><83>: Abbrev Number: 0
...

In case we only print ZERO, dwarf2_cu::setup_type_unit_groups is called for
CU@0x0, which calls start_symtab, which sets cu->list_in_scope to non-NULL.

In case we first print e, then:
- first dwarf2_cu::setup_type_unit_groups is called for CU@0x39, which calls
  start_symtab, which sets cu->list_in_scope to non-NULL, and
- then dwarf2_cu::setup_type_unit_groups is called for CU@0x0, which doesn't
  call start_symtab because first_time == 0, and cu->list_in_scope remains
NULL.

This patch fixes it:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 82564edd7b2..fde2b595040 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -10972,6 +10972,7 @@ dwarf2_cu::setup_type_unit_groups (struct die_info
*die)
                        COMPUNIT_DIRNAME (cust),
                        compunit_language (cust),
                        0, cust));
+      list_in_scope = get_builder ()->get_file_symbols ();

       auto &file_names = line_header->file_names ();
       for (i = 0; i < file_names.size (); ++i)
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug symtab/25886] [debug-types] FAIL: gdb.base/enumval.exp: p ZERO
  2020-04-28 11:53 [Bug symtab/25886] New: [debug-types] FAIL: gdb.base/enumval.exp: p ZERO vries at gcc dot gnu.org
  2020-04-28 12:18 ` [Bug symtab/25886] " vries at gcc dot gnu.org
@ 2020-04-28 12:19 ` vries at gcc dot gnu.org
  2020-04-28 14:44 ` vries at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: vries at gcc dot gnu.org @ 2020-04-28 12:19 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=25886

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> This patch fixes it:
> ...
> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> index 82564edd7b2..fde2b595040 100644
> --- a/gdb/dwarf2/read.c
> +++ b/gdb/dwarf2/read.c
> @@ -10972,6 +10972,7 @@ dwarf2_cu::setup_type_unit_groups (struct die_info
> *die)
>                         COMPUNIT_DIRNAME (cust),
>                         compunit_language (cust),
>                         0, cust));
> +      list_in_scope = get_builder ()->get_file_symbols ();
>  
>        auto &file_names = line_header->file_names ();
>        for (i = 0; i < file_names.size (); ++i)
> ...

Which looks remarkably like the patch from PR24480 comment 4.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug symtab/25886] [debug-types] FAIL: gdb.base/enumval.exp: p ZERO
  2020-04-28 11:53 [Bug symtab/25886] New: [debug-types] FAIL: gdb.base/enumval.exp: p ZERO vries at gcc dot gnu.org
  2020-04-28 12:18 ` [Bug symtab/25886] " vries at gcc dot gnu.org
  2020-04-28 12:19 ` vries at gcc dot gnu.org
@ 2020-04-28 14:44 ` vries at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: vries at gcc dot gnu.org @ 2020-04-28 14:44 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=25886

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> Which looks remarkably like the patch from PR24480 comment 4.

I've committed that patch (which was already approved), and retested this
test-case.  It passes now, so marking as duplicate.

*** This bug has been marked as a duplicate of bug 24480 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-04-28 14:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-28 11:53 [Bug symtab/25886] New: [debug-types] FAIL: gdb.base/enumval.exp: p ZERO vries at gcc dot gnu.org
2020-04-28 12:18 ` [Bug symtab/25886] " vries at gcc dot gnu.org
2020-04-28 12:19 ` vries at gcc dot gnu.org
2020-04-28 14:44 ` vries 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).