* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
@ 2021-06-22 5:26 ` simark at simark dot ca
2021-06-22 5:29 ` simark at simark dot ca
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: simark at simark dot ca @ 2021-06-22 5:26 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
Simon Marchi <simark at simark dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.1
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
2021-06-22 5:26 ` [Bug gdb/28004] " simark at simark dot ca
@ 2021-06-22 5:29 ` simark at simark dot ca
2021-06-25 7:03 ` vries at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: simark at simark dot ca @ 2021-06-22 5:29 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
Here are the repro files (45MB): https://files.efficios.com/s/WYnRRzPRbbdbbMg
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
2021-06-22 5:26 ` [Bug gdb/28004] " simark at simark dot ca
2021-06-22 5:29 ` simark at simark dot ca
@ 2021-06-25 7:03 ` vries at gcc dot gnu.org
2021-06-25 12:47 ` vries at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-06-25 7:03 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vries at gcc dot gnu.org
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (2 preceding siblings ...)
2021-06-25 7:03 ` vries at gcc dot gnu.org
@ 2021-06-25 12:47 ` vries at gcc dot gnu.org
2021-06-25 14:23 ` vries at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-06-25 12:47 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
The warning is caused by the fact that the addr map for the CU starts at 0, due
to the DW_AT_entry_pc:
...
<2><50bea>: Abbrev Number: 13 (DW_TAG_inlined_subroutine)
<50beb> DW_AT_abstract_origin: <0x50b99>
<50bef> DW_AT_entry_pc : 0x0
<50bf7> DW_AT_GNU_entry_view: 0
<50bf9> DW_AT_ranges : 0x3db4
<50bfd> DW_AT_call_file : 1
<50bfe> DW_AT_call_line : 64
<50bff> DW_AT_call_column : 9
<50c00> DW_AT_sibling : <0x50c26>
...
Or, likewise, DW_AT_ranges:
...
0x00003db4: [DW_RLE_base_address]: 0x0000000000000000
0x00003dbd: [DW_RLE_offset_pair ]: 0x0000000000000000, 0x0000000000000007 =>
[0x0000000000000000, 0x0000000000000007)
0x00003dc0: [DW_RLE_offset_pair ]: 0x000000000000000b, 0x0000000000000018 =>
[0x000000000000000b, 0x0000000000000018)
0x00003dc3: [DW_RLE_end_of_list ]
...
Perhaps this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99654 .
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (3 preceding siblings ...)
2021-06-25 12:47 ` vries at gcc dot gnu.org
@ 2021-06-25 14:23 ` vries at gcc dot gnu.org
2021-06-25 14:30 ` vries at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-06-25 14:23 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
If I just start gdb with the shared lib, and print the address map I get a very
reasonable:
...
(gdb) p /x map.transitions[0]
$16 = {addr = 0x0, value = 0x0}
(gdb) p /x map.transitions[1]
$17 = {addr = 0x99040, value = 0x1b236d0}
(gdb) p /x map.transitions[2]
$19 = {addr = 0x990bb, value = 0x0}
(gdb) p /x map.transitions[3]
$20 = {addr = 0x990bc, value = 0x1b236d0}
...
with 0x99040 being the start of the text segment:
...
Disassembly of section .text:
0000000000099040 <_ZNSi8ignoreXXEl.cold>:
99040: 48 83 e8 01 sub $0x1,%rax
...
990bb: 90 nop
00000000000990bc <_ZNSt13basic_istreamIwSt11char_traitsIwEE8ignoreXXEl.cold>:
...
But with the reproducer, I get:
...
(gdb) p /x map.transitions[0]
$30 = {addr = 0x0, value = 0x0}
(gdb) p /x map.transitions[1]
$31 = {addr = 0x0, value = 0x2deab60}
(gdb) p /x map.transitions[2]
$32 = {addr = 0x1d, value = 0x2591ce0}
(gdb) p /x map.transitions[3]
$33 = {addr = 0x4ef, value = 0x267bf00}
(gdb) p /x map.transitions[4]
$34 = {addr = 0xf72, value = 0x26c8ee0}
(gdb) p /x map.transitions[5]
$35 = {addr = 0x15eb, value = 0x0}
(gdb) p /x map.transitions[7]
$36 = {addr = 0x990bb, value = 0x0}
(gdb) p /x map.transitions[8]
$37 = {addr = 0x990bc, value = 0x1aced00}
...
Seems to be caused by this bit in dwarf2_rnglists_process:
...
/* A not-uncommon case of bad debug info.
Don't pollute the addrmap with bad data. */
if (range_beginning + baseaddr == 0
&& !per_objfile->per_bfd->has_section_at_zero)
{
complaint (_(".debug_rnglists entry has start address of zero"
" [in module %s]"), objfile_name (objfile));
continue;
}
...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (4 preceding siblings ...)
2021-06-25 14:23 ` vries at gcc dot gnu.org
@ 2021-06-25 14:30 ` vries at gcc dot gnu.org
2021-06-25 21:40 ` vries at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-06-25 14:30 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
This fixes the warning:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 07bc08fba14..96bfb1280e1 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -13604,7 +13604,6 @@ dwarf2_rnglists_process (unsigned offset, struct
dwarf2_cu *cu
,
/* Base address selection entry. */
gdb::optional<CORE_ADDR> base;
const gdb_byte *buffer;
- CORE_ADDR baseaddr;
bool overflow = false;
ULONGEST addr_index;
struct dwarf2_section_info *rnglists_section;
@@ -13621,8 +13620,6 @@ dwarf2_rnglists_process (unsigned offset, struct
dwarf2_cu *cu
,
}
buffer = rnglists_section->buffer + offset;
- baseaddr = objfile->text_section_offset ();
-
while (1)
{--
/* Initialize it due to a false compiler warning. */
@@ -13764,7 +13761,7 @@ dwarf2_rnglists_process (unsigned offset, struct
dwarf2_cu *cu
,
/* A not-uncommon case of bad debug info.
Don't pollute the addrmap with bad data. */
- if (range_beginning + baseaddr == 0
+ if (range_beginning == 0
&& !per_objfile->per_bfd->has_section_at_zero)
{
complaint (_(".debug_rnglists entry has start address of zero"
...
which means we no longer trigger the assert when rerunning. Doesn't fix the
assert as such though.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (5 preceding siblings ...)
2021-06-25 14:30 ` vries at gcc dot gnu.org
@ 2021-06-25 21:40 ` vries at gcc dot gnu.org
2021-06-27 13:14 ` simark at simark dot ca
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-06-25 21:40 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #4)
> This fixes the warning:
> ...
> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> index 07bc08fba14..96bfb1280e1 100644
> --- a/gdb/dwarf2/read.c
> +++ b/gdb/dwarf2/read.c
> @@ -13604,7 +13604,6 @@ dwarf2_rnglists_process (unsigned offset, struct
> dwarf2_cu *cu
> ,
> /* Base address selection entry. */
> gdb::optional<CORE_ADDR> base;
> const gdb_byte *buffer;
> - CORE_ADDR baseaddr;
> bool overflow = false;
> ULONGEST addr_index;
> struct dwarf2_section_info *rnglists_section;
> @@ -13621,8 +13620,6 @@ dwarf2_rnglists_process (unsigned offset, struct
> dwarf2_cu *cu
> ,
> }
> buffer = rnglists_section->buffer + offset;
>
> - baseaddr = objfile->text_section_offset ();
> -
> while (1)
> {--
> /* Initialize it due to a false compiler warning. */
> @@ -13764,7 +13761,7 @@ dwarf2_rnglists_process (unsigned offset, struct
> dwarf2_cu *cu
> ,
>
> /* A not-uncommon case of bad debug info.
> Don't pollute the addrmap with bad data. */
> - if (range_beginning + baseaddr == 0
> + if (range_beginning == 0
> && !per_objfile->per_bfd->has_section_at_zero)
> {
> complaint (_(".debug_rnglists entry has start address of zero"
> ...
> which means we no longer trigger the assert when rerunning. Doesn't fix the
> assert as such though.
There's similar code for .debug_ranges.
I've tested a patch with both fixes on openSUSE Leap 15.2 x86_64 (gcc 7.5.0,
using .debug_ranges), and on openSUSE Tumbleweed x86_64 (gcc 11.1.1, using
.debug_rnglists).
/me -> vacation for 1 week.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (6 preceding siblings ...)
2021-06-25 21:40 ` vries at gcc dot gnu.org
@ 2021-06-27 13:14 ` simark at simark dot ca
2021-07-26 16:17 ` vries at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: simark at simark dot ca @ 2021-06-27 13:14 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #6 from Simon Marchi <simark at simark dot ca> ---
> I've tested a patch with both fixes on openSUSE Leap 15.2 x86_64 (gcc 7.5.0,
> using .debug_ranges), and on openSUSE Tumbleweed x86_64 (gcc 11.1.1, using
> .debug_rnglists).
I took a look, and I agree that adding baseaddr here does not make sense, if
the goal is checking whether the range beginning is 0.
So in all these ranges generated by gcc:
DW_AT_name [DW_FORM_line_strp]
("/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc")
DW_AT_comp_dir [DW_FORM_line_strp]
("/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98")
DW_AT_ranges [DW_FORM_sec_offset] (0x00004b50
[0x0000000000000000, 0x0000000000000056)
[0x00000000000a4790, 0x00000000000a479c)
[0x00000000000a47a0, 0x00000000000a47ac)
[0x00000000000a47b0, 0x00000000000a47c8)
[0x0000000000000000, 0x0000000000000026)
[0x00000000000a47d0, 0x00000000000a47e8)
[0x0000000000000000, 0x0000000000000026)
[0x000000000009916c, 0x00000000000991a1)
[0x00000000000991a1, 0x00000000000991d6)
[0x00000000000b1e10, 0x00000000000b1e5b)
[0x0000000000000000, 0x0000000000000011)
[0x0000000000000000, 0x0000000000000011)
...
All those starting from 0 are just bad and should not be considered?
> /me -> vacation for 1 week.
Hope you have a good time!
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (7 preceding siblings ...)
2021-06-27 13:14 ` simark at simark dot ca
@ 2021-07-26 16:17 ` vries at gcc dot gnu.org
2021-07-29 19:19 ` simark at simark dot ca
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-07-26 16:17 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #6)
> > I've tested a patch with both fixes on openSUSE Leap 15.2 x86_64 (gcc 7.5.0,
> > using .debug_ranges), and on openSUSE Tumbleweed x86_64 (gcc 11.1.1, using
> > .debug_rnglists).
>
> I took a look, and I agree that adding baseaddr here does not make sense, if
> the goal is checking whether the range beginning is 0.
>
Ack.
> So in all these ranges generated by gcc:
>
> DW_AT_name [DW_FORM_line_strp]
> ("/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc")
> DW_AT_comp_dir [DW_FORM_line_strp]
> ("/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98")
> DW_AT_ranges [DW_FORM_sec_offset] (0x00004b50
> [0x0000000000000000, 0x0000000000000056)
> [0x00000000000a4790, 0x00000000000a479c)
> [0x00000000000a47a0, 0x00000000000a47ac)
> [0x00000000000a47b0, 0x00000000000a47c8)
> [0x0000000000000000, 0x0000000000000026)
> [0x00000000000a47d0, 0x00000000000a47e8)
> [0x0000000000000000, 0x0000000000000026)
> [0x000000000009916c, 0x00000000000991a1)
> [0x00000000000991a1, 0x00000000000991d6)
> [0x00000000000b1e10, 0x00000000000b1e5b)
> [0x0000000000000000, 0x0000000000000011)
> [0x0000000000000000, 0x0000000000000011)
>
> ...
>
> All those starting from 0 are just bad and should not be considered?
>
I guess so (The comment does mention that it's not uncommon).
> > /me -> vacation for 1 week.
>
> Hope you have a good time!
I did :)
I've finally found time to work on the test-case and managed to create a dwarf
assembly test-case for this (with .debug_ranges), so I'll probably submit the
fix + test-case this week. [ Perhaps a .debug_rnglists version can be made
easily as well, but I'll look into that after submission. ]
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (8 preceding siblings ...)
2021-07-26 16:17 ` vries at gcc dot gnu.org
@ 2021-07-29 19:19 ` simark at simark dot ca
2021-07-29 21:27 ` vries at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: simark at simark dot ca @ 2021-07-29 19:19 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #8 from Simon Marchi <simark at simark dot ca> ---
(In reply to Tom de Vries from comment #7)
> I've finally found time to work on the test-case and managed to create a
> dwarf assembly test-case for this (with .debug_ranges), so I'll probably
> submit the fix + test-case this week. [ Perhaps a .debug_rnglists version
> can be made easily as well, but I'll look into that after submission. ]
Thanks, let me know if you'd like me to help adding the finishing touches to
the fix and test, if you are caught up with other things.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (9 preceding siblings ...)
2021-07-29 19:19 ` simark at simark dot ca
@ 2021-07-29 21:27 ` vries at gcc dot gnu.org
2021-08-03 20:14 ` vries at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-07-29 21:27 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #8)
> (In reply to Tom de Vries from comment #7)
> > I've finally found time to work on the test-case and managed to create a
> > dwarf assembly test-case for this (with .debug_ranges), so I'll probably
> > submit the fix + test-case this week. [ Perhaps a .debug_rnglists version
> > can be made easily as well, but I'll look into that after submission. ]
>
> Thanks, let me know if you'd like me to help adding the finishing touches to
> the fix and test, if you are caught up with other things.
Thanks, I've just submitted (
https://sourceware.org/pipermail/gdb-patches/2021-July/181257.html ).
As mentioned before, this does not fix the assertion failure, so perhaps
there's still time to look into that. I might have time for that tomorrow.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (10 preceding siblings ...)
2021-07-29 21:27 ` vries at gcc dot gnu.org
@ 2021-08-03 20:14 ` vries at gcc dot gnu.org
2021-08-04 14:19 ` vries at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-08-03 20:14 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
Actual root cause analysis:
The following warning / Internal error is reported:
...
$ gdb -q -batch \
-iex "set sysroot $(pwd -P)/repro" \
./repro/gdb \
./repro/core \
-ex bt
...
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
[Current thread is 1 (LWP 1762498)]
#1 0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
but not in symtab.)
warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
but not in symtab.)
...
#2 0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \
[clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
psymtab, but not in symtab.)
) from repro/usr/lib/libstdc++.so.6
...
The warning is about the following:
- in find_pc_sect_compunit_symtab we try to find the address
(0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
- that fails, so we try again in the partial symtabs.
- we find a matching partial symtab
- however, the partial symtab has a matching symtab, so
we should have found a matching symtab in the first step.
The addresses are:
...
(gdb) info sym 0x7ff8feb2c218
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
section .text of repro/usr/lib/libstdc++.so.6
(gdb) info sym 0x7ff8feb2c21d
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
section .text of repro/usr/lib/libstdc++.so.6
...
which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
...
$ nm -C repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
[clone .cold]
...
which belong to function __gnu_debug::_Error_formatter::_M_error() in
/build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.
The partial symtab that is found for the addresses is instead the one for
/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
incorrect.
This happens due to 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);
...
and consequently, the addr_map get build using pc info from the functions [1].
During that process, addrmap_set_empty is called with a range that includes
0x9c218 and 0x9c21d:
...
(gdb) p /x start
$7 = 0x9989c
(gdb) p /x end_inclusive
$8 = 0xb200d
...
but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
...
000040ae 00000000000b1ee0 00000000000b200e
000040b9 000000000009989c 00000000000998c4
000040c3 <End of list>
...
which do not include 0x9c218 and 0x9c21d.
This is caused by this code:
...
if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
nullptr, tag))
has_pc_info = 1;
...
Disabling the has_pc_info assignment makes the warning go away.
[1] If we disable the code (in other words, we disable the workaround from PR
gdb/c++/15231 for a gcc-4.8 debug info problem):
...
- cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
+ cu_bounds_kind < PC_BOUNDS_INVALID, cu);
...
the warning disappears.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (11 preceding siblings ...)
2021-08-03 20:14 ` vries at gcc dot gnu.org
@ 2021-08-04 14:19 ` vries at gcc dot gnu.org
2021-08-06 14:44 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-08-04 14:19 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #0)
> Bisects to:
>
> commit 9f6c202e573b796a9e7328cc5fdab7c0c63776bf
> Author: Tom de Vries <tdevries@suse.de>
> Date: Mon Jan 25 16:32:31 2021 +0100
>
> [gdb/symtab] Handle DW_AT_ranges with DW_FORM_sec_off in partial DIE
And after carrying that patch during a further bisect, we get to:
...
commit 1b00ef063f8230a1f110cc5aeef04d3dc1338358
Author: Tom de Vries <tdevries@suse.de>
Date: Wed Oct 28 21:04:12 2020 +0100
[gdb/symtab] Fix language of frame without debug info
...
Which makes sense. This is essentially the psymtab variant of the bug fixed in
that commit for full symtabs.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (12 preceding siblings ...)
2021-08-04 14:19 ` vries at gcc dot gnu.org
@ 2021-08-06 14:44 ` cvs-commit at gcc dot gnu.org
2021-08-06 16:02 ` cvs-commit at gcc dot gnu.org
2021-08-06 16:05 ` [Bug symtab/28004] " vries at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-06 14:44 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #12 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=b9f3fbc9f3453bcb24fece0c46acf581d13d3f64
commit b9f3fbc9f3453bcb24fece0c46acf581d13d3f64
Author: Tom de Vries <tdevries@suse.de>
Date: Fri Aug 6 16:44:17 2021 +0200
[gdb/symtab] Fix zero address complaint for shlib
In PR28004 the following warning / Internal error is reported:
...
$ gdb -q -batch \
-iex "set sysroot $(pwd -P)/repro" \
./repro/gdb \
./repro/core \
-ex bt
...
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
[Current thread is 1 (LWP 1762498)]
#1 0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
but not in symtab.)
warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
but not in symtab.)
...
#2 0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const
\
[clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
psymtab, but not in symtab.)
) from repro/usr/lib/libstdc++.so.6
...
The warning is about the following:
- in find_pc_sect_compunit_symtab we try to find the address
(0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
- that fails, so we try again in the partial symtabs.
- we find a matching partial symtab
- however, the partial symtab has a full symtab, so
we should have found a matching symtab in the first step.
The addresses are:
...
(gdb) info sym 0x7ff8feb2c218
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
section .text of repro/usr/lib/libstdc++.so.6
(gdb) info sym 0x7ff8feb2c21d
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
section .text of repro/usr/lib/libstdc++.so.6
...
which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
...
$ nm -C repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
[clone .cold]
...
which belong to function __gnu_debug::_Error_formatter::_M_error() in
/build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.
The partial symtab that is found for the addresses is instead the one for
/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
incorrect.
This happens as follows.
The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset
0x4b50:
...
00004b50 0000000000000000 0000000000000056
00004b5a 00000000000a4790 00000000000a479c
00004b64 00000000000a47a0 00000000000a47ac
...
When reading the first range 0x0..0x56, it doesn't trigger the "start
address
of zero" complaint here:
...
/* A not-uncommon case of bad debug info.
Don't pollute the addrmap with bad data. */
if (range_beginning + baseaddr == 0
&& !per_objfile->per_bfd->has_section_at_zero)
{
complaint (_(".debug_rnglists entry has start address of zero"
" [in module %s]"), objfile_name (objfile));
continue;
}
...
because baseaddr != 0, which seems incorrect given that when loading the
shared library individually in gdb (and consequently baseaddr == 0), we do
see
the complaint.
Consequently, we run into this case in dwarf2_get_pc_bounds:
...
if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
return PC_BOUNDS_INVALID;
...
which then results in 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);
...
and consequently, the CU addrmap gets build using address info from the
functions.
During that process, addrmap_set_empty is called with a range that includes
0x9c218 and 0x9c21d:
...
(gdb) p /x start
$7 = 0x9989c
(gdb) p /x end_inclusive
$8 = 0xb200d
...
but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
...
000040ae 00000000000b1ee0 00000000000b200e
000040b9 000000000009989c 00000000000998c4
000040c3 <End of list>
...
and neither range includes 0x9c218 and 0x9c21d.
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 0x9989c..0xb200d,
which is indeed not the case.
This patch fixes the first problem encountered: fix the "start address of
zero" complaint warning by removing the baseaddr part from the condition.
Same for dwarf2_ranges_process.
The effect is that:
- the complaint is triggered, and
- the warning / Internal error is no longer triggered.
This does not fix the observed problem in partial_die_info::read, which is
filed as PR28200.
Tested on x86_64-linux.
Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
gdb/ChangeLog:
2021-07-29 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/28004
* gdb/dwarf2/read.c (dwarf2_rnglists_process,
dwarf2_ranges_process):
Fix zero address complaint.
* gdb/testsuite/gdb.dwarf2/dw2-zero-range-shlib.c: New test.
* gdb/testsuite/gdb.dwarf2/dw2-zero-range.c: New test.
* gdb/testsuite/gdb.dwarf2/dw2-zero-range.exp: New file.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug gdb/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (13 preceding siblings ...)
2021-08-06 14:44 ` cvs-commit at gcc dot gnu.org
@ 2021-08-06 16:02 ` cvs-commit at gcc dot gnu.org
2021-08-06 16:05 ` [Bug symtab/28004] " vries at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-06 16:02 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
--- Comment #13 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-11-branch branch has been updated by Tom de Vries
<vries@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a656ee0831bea07e57876aa933ce4fe2063c2355
commit a656ee0831bea07e57876aa933ce4fe2063c2355
Author: Tom de Vries <tdevries@suse.de>
Date: Fri Aug 6 18:02:28 2021 +0200
[gdb/symtab] Fix zero address complaint for shlib
In PR28004 the following warning / Internal error is reported:
...
$ gdb -q -batch \
-iex "set sysroot $(pwd -P)/repro" \
./repro/gdb \
./repro/core \
-ex bt
...
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
[Current thread is 1 (LWP 1762498)]
#1 0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
but not in symtab.)
warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
but not in symtab.)
...
#2 0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const
\
[clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
psymtab, but not in symtab.)
) from repro/usr/lib/libstdc++.so.6
...
The warning is about the following:
- in find_pc_sect_compunit_symtab we try to find the address
(0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
- that fails, so we try again in the partial symtabs.
- we find a matching partial symtab
- however, the partial symtab has a full symtab, so
we should have found a matching symtab in the first step.
The addresses are:
...
(gdb) info sym 0x7ff8feb2c218
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
section .text of repro/usr/lib/libstdc++.so.6
(gdb) info sym 0x7ff8feb2c21d
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
section .text of repro/usr/lib/libstdc++.so.6
...
which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
...
$ nm -C repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
[clone .cold]
...
which belong to function __gnu_debug::_Error_formatter::_M_error() in
/build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.
The partial symtab that is found for the addresses is instead the one for
/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
incorrect.
This happens as follows.
The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset
0x4b50:
...
00004b50 0000000000000000 0000000000000056
00004b5a 00000000000a4790 00000000000a479c
00004b64 00000000000a47a0 00000000000a47ac
...
When reading the first range 0x0..0x56, it doesn't trigger the "start
address
of zero" complaint here:
...
/* A not-uncommon case of bad debug info.
Don't pollute the addrmap with bad data. */
if (range_beginning + baseaddr == 0
&& !per_objfile->per_bfd->has_section_at_zero)
{
complaint (_(".debug_rnglists entry has start address of zero"
" [in module %s]"), objfile_name (objfile));
continue;
}
...
because baseaddr != 0, which seems incorrect given that when loading the
shared library individually in gdb (and consequently baseaddr == 0), we do
see
the complaint.
Consequently, we run into this case in dwarf2_get_pc_bounds:
...
if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
return PC_BOUNDS_INVALID;
...
which then results in 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);
...
and consequently, the CU addrmap gets build using address info from the
functions.
During that process, addrmap_set_empty is called with a range that includes
0x9c218 and 0x9c21d:
...
(gdb) p /x start
$7 = 0x9989c
(gdb) p /x end_inclusive
$8 = 0xb200d
...
but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
...
000040ae 00000000000b1ee0 00000000000b200e
000040b9 000000000009989c 00000000000998c4
000040c3 <End of list>
...
and neither range includes 0x9c218 and 0x9c21d.
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 0x9989c..0xb200d,
which is indeed not the case.
This patch fixes the first problem encountered: fix the "start address of
zero" complaint warning by removing the baseaddr part from the condition.
Same for dwarf2_ranges_process.
The effect is that:
- the complaint is triggered, and
- the warning / Internal error is no longer triggered.
This does not fix the observed problem in partial_die_info::read, which is
filed as PR28200.
Tested on x86_64-linux.
Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
gdb/ChangeLog:
2021-08-06 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/28004
* dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process):
Fix zero address complaint.
gdb/testsuite/ChangeLog:
2021-08-06 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/28004
* gdb.dwarf2/dw2-zero-range-shlib.c: New test.
* gdb.dwarf2/dw2-zero-range.c: New test.
* gdb.dwarf2/dw2-zero-range.exp: New file.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug symtab/28004] DW_AT_ranges with form DW_FORM_sec_offset problem
2021-06-22 5:26 [Bug gdb/28004] New: DW_AT_ranges with form DW_FORM_sec_offset problem simark at simark dot ca
` (14 preceding siblings ...)
2021-08-06 16:02 ` cvs-commit at gcc dot gnu.org
@ 2021-08-06 16:05 ` vries at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2021-08-06 16:05 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=28004
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
Component|gdb |symtab
--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch committed to master and gdb-11-branch.
Filed PR28200 for remaining issue.
Marking resolved-fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 17+ messages in thread