[Bug symtab/28200] New: DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[Bug symtab/28200] New: DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

            Bug ID: 28200
           Summary: DW_AT_ranges handling in partial_die_info::read does
                    not handle discontinuous ranges
           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 13596
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13596&action=edit
Test-case patch

[ Spinoff from PR28004. ]

Consider test-case dw2-ranges-psym/dw2-ranges-psym.exp.

Say we split up the range $foo_low_start $foo_low_end in two ranges:
...
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
b/gdb/testsuite/gdb.dwarf2/dw2-ranges-
psym.exp
index 3ad2d1c567c..84c9d87adfd 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
@@ -109,11 +109,13 @@ Dwarf::assemble $asm_file {
     ranges {is_64 [is_64_target]} {
        func_ranges_label: sequence {
            range $foo_start $foo_end
-           range $foo_low_start $foo_low_end
+           range $foo_low_start "$foo_low_start + 1"
+           range "$foo_low_start + 1" $foo_low_end
        }
        cu_ranges_label: sequence {
            range $foo_start $foo_end
-           range $foo_low_start $foo_low_end
+           range $foo_low_start "$foo_low_start + 1"
+           range "$foo_low_start + 1" $foo_low_end
            range $bar_start $bar_end
            range $baz_start $baz_end
        }
...

When printing the partial symbols:
...
$ gdb -q -batch outputs/gdb.dwarf2/dw2-ranges-psym/dw2-ranges-psym -ex "maint
print psymbols"
...
we find for CU dw-ranges-psym.c the address map, a single range:
...
  Address map:
    0x4004b2 0x383f140
    0x4004e7 <ends here>
...

Now say we remove the range range "$foo_low_start + 1" $foo_low_end from the cu
ranges.  Consequently the CU address map changes:
...
  Address map:
    0x4004b2 0x2c65140
    0x4004ba <ends here>
    0x4004c5 0x2c65140
    0x4004e7 <ends here>
...
and there's a hole at [0x4004ba - 0x4004c5).

Now say we remove the DW_AT_ranges for the CU, we get back:
...
  Address map:
    0x4004b2 0x391df20
    0x4004e7 <ends here>
...
What happens here, is that gdb puts together the address map from the
functions, triggered by this code in process_psymtab_comp_unit_reader being
called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
argument to 1:
...
          scan_partial_symbols (first_die, &lowpc, &highpc,
                                cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
...

Now say we remove the same range from the ranges for the function someothername
(an alias for foo). We get the address map:
...
  Address map:
    0x4004b2 0x3b69140
    0x4004e7 <ends here>
...

This is incorrect, the hole is missing.

This is caused by this code in partial_die_info::read:
...
            if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
                                    nullptr, tag))
              has_pc_info = 1;
...
which pretends that the function is located at addresses lowpc...highpc, which
is indeed not the case.

Using attached test-case patch, we modify the test-case a bit more to get:
...
(gdb) bt
warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

#0  0x00000000004004bb in baz ()
warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

#1  0x00000000004004c7 in foo_low (warning: (Internal error: pc 0x4004c6 in
read in psymtab, but not in symtab.)

)
#2  0x00000000004004e9 in someothername ()
#3  0x00000000004004b0 in main ()
(gdb) PASS: gdb.dwarf2/dw2-ranges-psym.exp: bt
...

The warning complains about the fact that a pc in the range that was removed
can be found in the psymtab (due to the bug described above) but cannot be
found in the corresponding symtab (because that one accurately handles
discontinuous ranges).

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca,
                   |                            |tromey at sourceware dot org

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Using this hack:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index bac02b5a1bd..394e69b79d3 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -19327,7 +19327,10 @@ partial_die_info::read (const struct die_reader_specs
*reader,

            if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
                                    nullptr, tag))
-             has_pc_info = 1;
+             {
+               highpc = lowpc + 1;
+               has_pc_info = 1;
+             }
          }
          break;

...
gets rid of the warning:
...
(gdb) bt^M
#0  0x00000000004004bb in baz ()^M
#1  0x00000000004004c7 in foo_low ()^M
#2  0x00000000004004e9 in someothername ()^M
#3  0x00000000004004b0 in main ()^M
(gdb) PASS: gdb.dwarf2/dw2-ranges-psym.exp: bt
...
while allowing the original test-case (so without the patch applied) still to
pass.

But it basically inverts the problem: instead of claiming too much addresses in
the partial symtab, it claims to few, so I guess this is really a hack rather
than a fix.  With this hack, I expect problems of the sort of:
- trying to find an address in full symtabs fails (because the corresponding
  partial symtab is not expanded yet)
- trying to find address in partial symtabs fails (because of the hack)
- we conclude we can't find any debug info corresponding to the address, which
  is incorrect.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Essentially, there are two interpretations of has_pc_info:
- this is not something to be ignored, build a symbol in the partial symbol
  table
- the field lowpc and highpc are valid.

The code:
...
            if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
                                    nullptr, tag))
              has_pc_info = 1;
...
uses the first interpretation to fix the problem that a symbol is not listed in
the partial symbol table.

Which also implies the second interpretation, which apparently usually doesn't
cause much trouble, but evidently it does in combination with this workaround
for gcc 4.8 (see PR15231):
...
          scan_partial_symbols (first_die, &lowpc, &highpc,
                                cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
...

So, at this point I see two potential solutions:
- add an address map along side lowpc/highpc and pass that instead of nullptr
to 
  dwarf2_ranges_read, and handle things from there-on
- split up the two interpretations of has_pc_info, say by adding
  highlowpc_valid (or have_ranges), and when encountering DW_AT_ranges
  just mark highlowpc_valid = 0 and has_pc_info = 1, and deferring reading
  the ranges till we have the partial symtab address map to work with.

My guess is that the latter is more space-efficient.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[simark at simark dot ca]

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

--- Comment #3 from Simon Marchi <simark at simark dot ca> ---
(In reply to Tom de Vries from comment #0)
> What happens here, is that gdb puts together the address map from the
> functions, triggered by this code in process_psymtab_comp_unit_reader being
> called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
> argument to 1:
> ...
>           scan_partial_symbols (first_die, &lowpc, &highpc,
>                                 cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
> ...

I'm trying to reproduce to understand better what you mean and I lose you here.
 I'm at:

(top-gdb) frame
#0  process_psymtab_comp_unit_reader (reader=0x7fffffffc3e0,
info_ptr=0x60c000014faa "\003\004\005integer", comp_unit_die=0x621000163110,
pretend_language=language_minimal) at
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:6941
6941      if (cu_bounds_kind == PC_BOUNDS_HIGH_LOW && best_lowpc < best_highpc)


And cu_bounds_kind is:

(top-gdb) p cu_bounds_kind
$9 = PC_BOUNDS_RANGES

Not PC_BOUNDS_INVALID.

This is with the test case modified as you explained, with the separate but
contiguous ranges:

0x0000000b: DW_TAG_compile_unit
              DW_AT_language [DW_FORM_sdata]    (2)
              DW_AT_name [DW_FORM_string]       ("dw-ranges-psym.c")
              DW_AT_low_pc [DW_FORM_addr]       (0x0000000000000000)
              DW_AT_ranges [DW_FORM_sec_offset] (0x00000040
                 [0x000000000000113e, 0x0000000000001159)
                 [0x000000000000112b, 0x000000000000112c)
                 [0x000000000000112c, 0x0000000000001137)
                 [0x0000000000001137, 0x000000000000113e)
                 [0x0000000000001124, 0x000000000000112b))

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
[ Refiling comment 0, a bit restructured for better readability, and the
ability to refer to individual parts. Also a minor correction on cu_bounds_kind
in case IV.  Also added the initial, unmodified case as starting point. ]


I.

Consider test-case dw2-ranges-psym/dw2-ranges-psym.exp, unmodified.

When printing the partial symbols:
...
$ gdb -q -batch outputs/gdb.dwarf2/dw2-ranges-psym/dw2-ranges-psym -ex "maint
print psymbols"
...
we find for CU dw-ranges-psym.c the address map, a single range:
...
  Address map:
    0x4004b2 0x383f140
    0x4004e7 <ends here>
...


II.

Say we split up the range $foo_low_start $foo_low_end in two ranges:
...
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
b/gdb/testsuite/gdb.dwarf2/dw2-ranges-
psym.exp
index 3ad2d1c567c..84c9d87adfd 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
@@ -109,11 +109,13 @@ Dwarf::assemble $asm_file {
     ranges {is_64 [is_64_target]} {
        func_ranges_label: sequence {
            range $foo_start $foo_end
-           range $foo_low_start $foo_low_end
+           range $foo_low_start "$foo_low_start + 1"
+           range "$foo_low_start + 1" $foo_low_end
        }
        cu_ranges_label: sequence {
            range $foo_start $foo_end
-           range $foo_low_start $foo_low_end
+           range $foo_low_start "$foo_low_start + 1"
+           range "$foo_low_start + 1" $foo_low_end
            range $bar_start $bar_end
            range $baz_start $baz_end
        }
...

When printing the partial symbols, we get the same, a single range:
...
  Address map:
    0x4004b2 0x383f140
    0x4004e7 <ends here>
...


III.

Now say we remove the range range "$foo_low_start + 1" $foo_low_end from the cu
ranges:
...
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
b/gdb/testsuite/gdb.dwarf2/dw2-ranges-
psym.exp
index 84c9d87adfd..61014f288fe 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
@@ -115,7 +115,6 @@ Dwarf::assemble $asm_file {
        cu_ranges_label: sequence {
            range $foo_start $foo_end
            range $foo_low_start "$foo_low_start + 1"
-           range "$foo_low_start + 1" $foo_low_end
            range $bar_start $bar_end
            range $baz_start $baz_end
        }
...

Consequently the CU address map changes:
...
  Address map:
    0x4004b2 0x2c65140
    0x4004ba <ends here>
    0x4004c5 0x2c65140
    0x4004e7 <ends here>
...
and there's a hole at [0x4004ba - 0x4004c5).


IV.

Now say we remove the DW_AT_ranges for the CU:
...
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
b/gdb/testsuite/gdb.dwarf2/dw2-ranges-
psym.exp
index 61014f288fe..4e3c848e279 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
@@ -75,7 +75,6 @@ Dwarf::assemble $asm_file {
            {language @DW_LANG_C}
            {name dw-ranges-psym.c}
            {low_pc 0 addr}
-           {ranges ${cu_ranges_label} DW_FORM_sec_offset}
        } {
            integer_label: DW_TAG_base_type {
                {DW_AT_byte_size $int_size DW_FORM_sdata}
...

We get back:
...
  Address map:
    0x4004b2 0x391df20
    0x4004e7 <ends here>
...

What happens here, is that gdb puts together the address map from the
functions, triggered by this code in process_psymtab_comp_unit_reader being
called with cu_bounds_kind == PC_BOUNDS_NOT_PRESENT (and not PC_BOUNDS_INVALID
as I said mistakingly in comment 0), which sets the set_addrmap argument to 1:
...
          scan_partial_symbols (first_die, &lowpc, &highpc,
                                cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
...


V.

Now say we remove the same range from the ranges for the function someothername
(an alias for foo):
...
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
b/gdb/testsuite/gdb.dwarf2/dw2-ranges-
psym.exp
index 4e3c848e279..7b628bceceb 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-psym.exp
@@ -109,7 +109,6 @@ Dwarf::assemble $asm_file {
        func_ranges_label: sequence {
            range $foo_start $foo_end
            range $foo_low_start "$foo_low_start + 1"
-           range "$foo_low_start + 1" $foo_low_end
        }
        cu_ranges_label: sequence {
            range $foo_start $foo_end
...

We get the address map:
...
  Address map:
    0x4004b2 0x3b69140
    0x4004e7 <ends here>
...

This is incorrect, the hole is missing.

This is caused by this code in partial_die_info::read:
...
            if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
                                    nullptr, tag))
              has_pc_info = 1;
...
which pretends that the function is located at addresses lowpc...highpc, which
is indeed not the case.


VI.

Using attached test-case patch, we modify the test-case a bit more to get:
...
(gdb) bt
warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

#0  0x00000000004004bb in baz ()
warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x4004c6 in read in psymtab, but not in symtab.)

#1  0x00000000004004c7 in foo_low (warning: (Internal error: pc 0x4004c6 in
read in psymtab, but not in symtab.)

)
#2  0x00000000004004e9 in someothername ()
#3  0x00000000004004b0 in main ()
(gdb) PASS: gdb.dwarf2/dw2-ranges-psym.exp: bt
...

The warning complains about the fact that a pc in the range that was removed
can be found in the psymtab (due to the bug described above) but cannot be
found in the corresponding symtab (because that one accurately handles
discontinuous ranges).

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #3)
> (In reply to Tom de Vries from comment #0)
> > What happens here, is that gdb puts together the address map from the
> > functions, triggered by this code in process_psymtab_comp_unit_reader being
> > called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
> > argument to 1:
> > ...
> >           scan_partial_symbols (first_die, &lowpc, &highpc,
> >                                 cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
> > ...
> 
> I'm trying to reproduce to understand better what you mean and I lose you
> here.  I'm at:
> 
> (top-gdb) frame
> #0  process_psymtab_comp_unit_reader (reader=0x7fffffffc3e0,
> info_ptr=0x60c000014faa "\003\004\005integer", comp_unit_die=0x621000163110,
> pretend_language=language_minimal) at
> /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:6941
> 6941      if (cu_bounds_kind == PC_BOUNDS_HIGH_LOW && best_lowpc <
> best_highpc)
> 
> 
> And cu_bounds_kind is:
> 
> (top-gdb) p cu_bounds_kind
> $9 = PC_BOUNDS_RANGES
> 
> Not PC_BOUNDS_INVALID.
> 
> This is with the test case modified as you explained, with the separate but
> contiguous ranges:
> 
> 0x0000000b: DW_TAG_compile_unit
>               DW_AT_language [DW_FORM_sdata]    (2)
>               DW_AT_name [DW_FORM_string]       ("dw-ranges-psym.c")
>               DW_AT_low_pc [DW_FORM_addr]       (0x0000000000000000)
>               DW_AT_ranges [DW_FORM_sec_offset] (0x00000040
>                  [0x000000000000113e, 0x0000000000001159)
>                  [0x000000000000112b, 0x000000000000112c)
>                  [0x000000000000112c, 0x0000000000001137)
>                  [0x0000000000001137, 0x000000000000113e)
>                  [0x0000000000001124, 0x000000000000112b))

AFAIU, the "separate but contiguous ranges" maps to case II.

Indeed, in case II we expect to see PC_BOUNDS_RANGES (and the same in case I
and III).  It's only in case IV that we expect something different:
PC_BOUND_NOT_PRESENT (not PC_BOUNDS_INVALID, my mistake).

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[simark at simark dot ca]

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

--- Comment #6 from Simon Marchi <simark at simark dot ca> ---
Here's my interpretation of your post, just to make sure I understand
correctly.

I. Looks correct
II. Looks correct
III. Now it sounds like bad debug info, because the CU's ranges is not a
superset of its children.  Unless GDB knows better (producer X produces wrong
CU ranges), I think it is correct to trust the CU's ranges, so the result shown
looks correct.  (I wouldn't mind having a maintenance mode where we compute the
ranges from the CU's children even if the CU has ranges, and compare the two
address maps to see if there's a difference.  That could mean a bug in GDB or
in the debug info.)
IV. When the CU doesn't provide ranges, we fall back on building an address map
that is the intersection of everything found under the CU.  At this point it
looks correct, because you still haven't put a "hole" in the function's ranges.
V. Now that you've put a hole in the function's ranges, we should see the hole,
therefore it's incorrect.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #6)
> Here's my interpretation of your post, just to make sure I understand
> correctly.
> 

Thanks for verifying.

> I. Looks correct
> II. Looks correct

Ack.

> III. Now it sounds like bad debug info, because the CU's ranges is not a
> superset of its children.

Hmm, I didn't consider this, but I also think it doesn't matter.  It's
trivially easy to make the function range info match the one of the CU, and
we'll see the same address map.

> Unless GDB knows better (producer X produces
> wrong CU ranges), I think it is correct to trust the CU's ranges, so the
> result shown looks correct.

Agreed.

> (I wouldn't mind having a maintenance mode
> where we compute the ranges from the CU's children even if the CU has
> ranges, and compare the two address maps to see if there's a difference. 
> That could mean a bug in GDB or in the debug info.)

Nice idea :)

> IV. When the CU doesn't provide ranges, we fall back on building an address
> map that is the intersection of everything found under the CU.  At this
> point it looks correct, because you still haven't put a "hole" in the
> function's ranges.

Ack.

> V. Now that you've put a hole in the function's ranges, we should see the
> hole, therefore it's incorrect.

To be specific, my understanding is that the gdb behaviour is incorrect, but
that the debug info is correct.  Agreed, there is no actual hole in the
function, we're just pretending that, but there could be.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[simark at simark dot ca]

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

--- Comment #8 from Simon Marchi <simark at simark dot ca> ---
(In reply to Tom de Vries from comment #7)
> > V. Now that you've put a hole in the function's ranges, we should see the
> > hole, therefore it's incorrect.
> 
> To be specific, my understanding is that the gdb behaviour is incorrect, but
> that the debug info is correct.  Agreed, there is no actual hole in the
> function, we're just pretending that, but there could be.

Right, I was unclear.  The debug info with a hole in the function's range is
totally valid, GDB's behavior is incorrect.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 13612
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13612&action=edit
Patch

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2021-August/181398.html

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.1

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
Tentatively setting milestone 11.1.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[brobecker at gnat dot com]

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

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brobecker at gnat dot com

--- Comment #12 from Joel Brobecker <brobecker at gnat dot com> ---
(In reply to Tom de Vries from comment #11)
> Tentatively setting milestone 11.1.

Hi Tom; Can you explain the reasons leading you to setting the milestone to
11.1. From my point of view, this is signaling that we must wait for this issue
to be fixed before we create the 11.1 release. I'm not opposed, but with the
information I'm seeing in this PR so far, I am not sure the reasons are
sufficiently strong that we want to delay the release even further (issues
seems minor in nature)...

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.1                        |12.1

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Joel Brobecker from comment #12)
> (In reply to Tom de Vries from comment #11)
> > Tentatively setting milestone 11.1.
> 
> Hi Tom; Can you explain the reasons leading you to setting the milestone to
> 11.1. From my point of view, this is signaling that we must wait for this
> issue to be fixed before we create the 11.1 release. I'm not opposed, but
> with the information I'm seeing in this PR so far, I am not sure the reasons
> are sufficiently strong that we want to delay the release even further
> (issues seems minor in nature)...

I guess I set it to 11.1 hoping to squeeze it in, provided I get review in
time.  

I agree, making the release wait for this is not reasonable.  Setting milestone
to 12.1.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=211aafd18d10b7739a16df5cc637952fd3f508e8

commit 211aafd18d10b7739a16df5cc637952fd3f508e8
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Sep 14 14:41:27 2021 +0200

    [gdb/symtab] Fix function range handling in psymtabs

    Consider the test-case from this patch.

    We run into:
    ...
    (gdb) PASS: gdb.dwarf2/dw2-ranges-psym-warning.exp: continue
    bt^M
    warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in
symtab.)^M
    ^M
    warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in
symtab.)^M
    ^M
    warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in
symtab.)^M
    ^M
    warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in
symtab.)^M
    ^M
    warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in
symtab.)^M
    ^M
    warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in
symtab.)^M
    ^M
      read in psymtab, but not in symtab.)^M
    ^M
    )^M
    (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: bt
    ...

    This happens as follows.

    The function foo:
    ...
     <1><31>: Abbrev Number: 4 (DW_TAG_subprogram)
        <33>   DW_AT_name        : foo
        <37>   DW_AT_ranges      : 0x0
    ...
    has these ranges:
    ...
        00000000 00000000004004c1 00000000004004d2
        00000000 00000000004004ae 00000000004004af
        00000000 <End of list>
    ...
    which have a hole at at [0x4004af,0x4004c1).

    However, the address map of the partial symtabs incorrectly maps addresses
    in the hole (such as 0x4004b6 in the backtrace) to the foo CU.

    The address map of the full symbol table of the foo CU however does not
    contain the addresses in the hole, which is what the warning / internal
error
    complains about.

    Fix this by making sure that ranges of functions are read correctly.

    The patch adds a bit to struct partial_die_info, in this hole (shown for
    x86_64-linux):
    ...
    /*   11: 7   |     4 */    unsigned int canonical_name : 1;
    /* XXX  4-byte hole  */
    /*   16      |     8 */    const char *raw_name;
    ...
    So there's no increase in size for 64-bit, but AFAIU there will be an
increase
    for 32-bit.

    Tested on x86_64-linux.

    gdb/ChangeLog:

    2021-08-10  Tom de Vries  <tdevries@suse.de>

            PR symtab/28200
            * dwarf2/read.c (struct partial_die_info): Add has_range_info and
            range_offset field.
            (add_partial_subprogram): Handle pdi->has_range_info.
            (partial_die_info::read): Set pdi->has_range_info.

    gdb/testsuite/ChangeLog:

    2021-08-10  Tom de Vries  <tdevries@suse.de>

            PR symtab/28200
            * gdb.dwarf2/dw2-ranges-psym-warning-main.c: New test.
            * gdb.dwarf2/dw2-ranges-psym-warning.c: New test.
            * gdb.dwarf2/dw2-ranges-psym-warning.exp: New file.

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

[Bug symtab/28200] DW_AT_ranges handling in partial_die_info::read does not handle discontinuous ranges

[vries at gcc dot gnu.org]

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

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

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

--- Comment #15 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=211aafd18d10b7739a16df5cc637952fd3f508e8
:

[gdb/symtab] Fix function range handling in psymtabs

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