* [PATCH] Ignore 0,0 entries in .debug_aranges
@ 2022-04-14 15:39 Tom Tromey
2022-04-14 17:04 ` Pedro Alves
2022-06-10 17:00 ` Jim Wilson
0 siblings, 2 replies; 3+ messages in thread
From: Tom Tromey @ 2022-04-14 15:39 UTC (permalink / raw)
To: gdb-patches; +Cc: Tom Tromey
When running the internal AdaCore test suite against the new DWARF
indexer, I found one regression on RISC-V. The test in question uses
--gc-sections, and winds up with an entry in the middle of a
.debug_aranges that has both address and length of 0. In this
scenario, gdb assumes the entries are terminated and then proceeds to
reject the section because it reads a subsequent entry as if it were a
header.
It seems to me that, because each header describes the size of each
.debug_aranges CU, it's better to simply ignore 0,0 entries and simply
read to the end. That is what this patch does.
I've patched an existing test to provide a regression test for this.
---
gdb/dwarf2/read.c | 11 +++++++++--
.../gdb.dwarf2/locexpr-data-member-location.exp | 3 +++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 698720276a9..6dcd446e5f4 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -2469,7 +2469,7 @@ read_addrmap_from_aranges (dwarf2_per_objfile *per_objfile,
bytes. */
addr += (entry_end - addr) % (2 * address_size);
- for (;;)
+ while (addr < entry_end)
{
if (addr + 2 * address_size > entry_end)
{
@@ -2487,7 +2487,14 @@ read_addrmap_from_aranges (dwarf2_per_objfile *per_objfile,
dwarf5_byte_order);
addr += address_size;
if (start == 0 && length == 0)
- break;
+ {
+ /* This can happen on some targets with --gc-sections.
+ This pair of values is also used to mark the end of
+ the entries for a given CU, but we ignore it and
+ instead handle termination using the check at the top
+ of the loop. */
+ continue;
+ }
if (start == 0 && !per_bfd->has_section_at_zero)
{
/* Symbol was eliminated due to a COMDAT group. */
diff --git a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
index 67e96fb1128..adb4e0a4c21 100644
--- a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
+++ b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
@@ -296,6 +296,9 @@ Dwarf::assemble ${asm_file} {
}
aranges {} cu_label {
+ # This 0,0 entry tests that the .debug_aranges reader can
+ # handle an apparent terminator before the end of the ranges.
+ arange {} 0 0
arange {} $foo_start $foo_end
arange {} $bar_start $bar_end
}
--
2.34.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Ignore 0,0 entries in .debug_aranges
2022-04-14 15:39 [PATCH] Ignore 0,0 entries in .debug_aranges Tom Tromey
@ 2022-04-14 17:04 ` Pedro Alves
2022-06-10 17:00 ` Jim Wilson
1 sibling, 0 replies; 3+ messages in thread
From: Pedro Alves @ 2022-04-14 17:04 UTC (permalink / raw)
To: Tom Tromey, gdb-patches
On 2022-04-14 16:39, Tom Tromey via Gdb-patches wrote:
> When running the internal AdaCore test suite against the new DWARF
> indexer, I found one regression on RISC-V. The test in question uses
> --gc-sections, and winds up with an entry in the middle of a
> .debug_aranges that has both address and length of 0. In this
> scenario, gdb assumes the entries are terminated and then proceeds to
> reject the section because it reads a subsequent entry as if it were a
> header.
>
> It seems to me that, because each header describes the size of each
> .debug_aranges CU, it's better to simply ignore 0,0 entries and simply
> read to the end. That is what this patch does.
>
> I've patched an existing test to provide a regression test for this.
Makes sense to me.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Ignore 0,0 entries in .debug_aranges
2022-04-14 15:39 [PATCH] Ignore 0,0 entries in .debug_aranges Tom Tromey
2022-04-14 17:04 ` Pedro Alves
@ 2022-06-10 17:00 ` Jim Wilson
1 sibling, 0 replies; 3+ messages in thread
From: Jim Wilson @ 2022-06-10 17:00 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Thu, Apr 14, 2022 at 8:39 AM Tom Tromey via Gdb-patches <
gdb-patches@sourceware.org> wrote:
> When running the internal AdaCore test suite against the new DWARF
> indexer, I found one regression on RISC-V. The test in question uses
> --gc-sections, and winds up with an entry in the middle of a
> .debug_aranges that has both address and length of 0. In this
> scenario, gdb assumes the entries are terminated and then proceeds to
> reject the section because it reads a subsequent entry as if it were a
> header.
>
FYI There is also an elfutils bug for this.
https://sourceware.org/bugzilla/show_bug.cgi?id=27805
I don't think the elfutils problem has been fixed yet. I did notice that I
got different results for RISC-V and x86_64. RISC-V gave me 0,0 pairs
which is wrong, but x86_64 gave me 0,4 pairs which is OK. I don't know why
the difference; I didn't investigate.
Jim
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-06-10 17:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-14 15:39 [PATCH] Ignore 0,0 entries in .debug_aranges Tom Tromey
2022-04-14 17:04 ` Pedro Alves
2022-06-10 17:00 ` Jim Wilson
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).