[Bug symtab/30846] New: [gdb/symtab] incorrect parent for forward spec (inter-cu case)

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 30846
           Summary: [gdb/symtab] incorrect parent for forward spec
                    (inter-cu case)
           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: ---

Created attachment 15109
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15109&action=edit
Dwarf assembly test-case demonstrating problem

Consider the attached dwarf assembly test-case, an inter-cu variant of
gdb.dwarf2/forward-spec.exp.

When we run it we get:
...
FAIL: gdb.dwarf2/forward-spec-inter-cu.exp: v has a parent
...
because:
...
    [3] ((cooked_index_entry *) 0x7f3b54005250)^M
    name:       v^M
    canonical:  v^M
    qualified:  v^M
    DWARF tag:  DW_TAG_variable^M
    flags:      0x2 [IS_STATIC]^M
    DIE offset: 0xbe^M
    parent:     ((cooked_index_entry *) 0)^M
...

The dwarf for the test-case is:
...
  Compilation Unit @ offset 0xb1:
 ...
 <0><bc>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <bd>   DW_AT_language    : 4        (C++)
 <1><be>: Abbrev Number: 3 (DW_TAG_variable)
    <bf>   DW_AT_specification: <0xe2>
    <c3>   DW_AT_location    : 3 byte block: 8 17 9f    (DW_OP_const1u: 23;
DW_OP_stack_value)
  ...
  Compilation Unit @ offset 0xc8:
  ...
 <0><d3>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <d4>   DW_AT_language    : 4        (C++)
  ...
 <1><de>: Abbrev Number: 4 (DW_TAG_namespace)
    <df>   DW_AT_name        : ns
 <2><e2>: Abbrev Number: 5 (DW_TAG_variable)
    <e3>   DW_AT_name        : v
    <e5>   DW_AT_type        : <0xd5>
    <e9>   DW_AT_declaration : 1
...

By looking at the compile unit offsets:
...
$ grep @ READELF
  Compilation Unit @ offset 0x0:
  Compilation Unit @ offset 0x45:
  Compilation Unit @ offset 0x84:
  Compilation Unit @ offset 0xa6:
  Compilation Unit @ offset 0xb1:
  Compilation Unit @ offset 0xc8:
  Compilation Unit @ offset 0xeb:
  Compilation Unit @ offset 0xf6:
  Compilation Unit @ offset 0x2ae:
...
we see that the 5th and 6th CUs are involved.

And then using the parallel_for_each_debug output:
...
Parallel for: n_elements: 9^M
Parallel for: total_size: 720^M
Parallel for: size_per_thread: 60^M
Parallel for: elements on worker thread 0       : 1     (size: 69)^M
Parallel for: elements on worker thread 1       : 1     (size: 63)^M
Parallel for: elements on worker thread 2       : 3     (size: 68)^M
Parallel for: elements on worker thread 3       : 3     (size: 486)^M
Parallel for: elements on worker thread 4       : 0     (size: 0)^M
Parallel for: elements on worker thread 5       : 0     (size: 0)^M
Parallel for: elements on worker thread 6       : 0     (size: 0)^M
Parallel for: elements on worker thread 7       : 0     (size: 0)^M
Parallel for: elements on worker thread 8       : 0     (size: 0)^M
Parallel for: elements on worker thread 9       : 0     (size: 0)^M
Parallel for: elements on worker thread 10      : 0     (size: 0)^M
Parallel for: elements on worker thread 11      : 0     (size: 0)^M
Parallel for: elements on main thread           : 1     (size: 0)^M
...
we can conclude that the 5th CU is in the 3rd shard, and the 6th CU is in the
4th shard.

So we managed to catch the inter-shard case.

[ It would be good to have a parallel-for mode that reserves a shard per item,
such that we can enforce this, independent of factors like amount of
worker-threads. ]

FWIW, also if we set worker-threads to 0, this still fails.  Both the
inter-shard and the intra-shard inter-cu case are broken.

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