Bug 25886 - [debug-types] FAIL: gdb.base/enumval.exp: p ZERO
Summary: [debug-types] FAIL: gdb.base/enumval.exp: p ZERO
Status: RESOLVED DUPLICATE of bug 24480
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-28 11:53 UTC by Tom de Vries
Modified: 2020-04-28 14:44 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2020-04-28 11:53:52 UTC
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
...
Comment 1 Tom de Vries 2020-04-28 12:18:17 UTC
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)
...
Comment 2 Tom de Vries 2020-04-28 12:19:08 UTC
(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.
Comment 3 Tom de Vries 2020-04-28 14:44:45 UTC
(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 ***