public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Ignore .debug_types when reading .debug_aranges
@ 2021-08-08 15:39 Tom Tromey
  2021-08-09 12:27 ` Simon Marchi
  0 siblings, 1 reply; 2+ messages in thread
From: Tom Tromey @ 2021-08-08 15:39 UTC (permalink / raw)
  To: gdb-patches; +Cc: Tom Tromey

I noticed that the fission-reread.exp test case can cause a complaint
when run with --target_board=cc-with-debug-names:

warning: Section .debug_aranges in [...]/fission-reread has duplicate debug_info_offset 0x0, ignoring .debug_aranges.

The bug here is that this executable has both .debug_info and
.debug_types, and both have a CU at offset 0x0.  This triggers the
duplicate warning.

Because .debug_types doesn't provide any address ranges, these CUs can
be ignored.  That is, this bug turns out to be another regression from
the info/types merger patch.

This patch fixes the problem by having this loop igore type units.
fission-reread.exp is updated to test for the bug.
---
 gdb/dwarf2/read.c                           | 6 ++++++
 gdb/testsuite/gdb.dwarf2/fission-reread.exp | 3 ++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 8dc2be6f176..2e85deeaa39 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -2536,6 +2536,12 @@ create_addrmap_from_aranges (dwarf2_per_objfile *per_objfile,
     debug_info_offset_to_per_cu;
   for (const auto &per_cu : per_bfd->all_comp_units)
     {
+      /* A TU will not need aranges, and skipping them here is an easy
+	 way of ignoring .debug_types -- and possibly seeing a
+	 duplicate section offset -- entirely.  */
+      if (per_cu->is_debug_types)
+	continue;
+
       const auto insertpair
 	= debug_info_offset_to_per_cu.emplace (per_cu->sect_off,
 					       per_cu.get ());
diff --git a/gdb/testsuite/gdb.dwarf2/fission-reread.exp b/gdb/testsuite/gdb.dwarf2/fission-reread.exp
index 16a139eb0cd..661e90b2f21 100644
--- a/gdb/testsuite/gdb.dwarf2/fission-reread.exp
+++ b/gdb/testsuite/gdb.dwarf2/fission-reread.exp
@@ -47,7 +47,8 @@ if [build_executable_and_dwo_files "$testfile.exp" "${binfile}" $options \
     return -1
 }
 
-clean_restart $binfile
+clean_restart
+gdb_load_no_complaints $binfile
 
 gdb_test "break -q main" "Breakpoint.*at.*"
 
-- 
2.31.1


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] Ignore .debug_types when reading .debug_aranges
  2021-08-08 15:39 [PATCH] Ignore .debug_types when reading .debug_aranges Tom Tromey
@ 2021-08-09 12:27 ` Simon Marchi
  0 siblings, 0 replies; 2+ messages in thread
From: Simon Marchi @ 2021-08-09 12:27 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches



On 2021-08-08 11:39 a.m., Tom Tromey wrote:
> I noticed that the fission-reread.exp test case can cause a complaint
> when run with --target_board=cc-with-debug-names:
> 
> warning: Section .debug_aranges in [...]/fission-reread has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
> 
> The bug here is that this executable has both .debug_info and
> .debug_types, and both have a CU at offset 0x0.  This triggers the
> duplicate warning.
> 
> Because .debug_types doesn't provide any address ranges, these CUs can
> be ignored.  That is, this bug turns out to be another regression from
> the info/types merger patch.
> 
> This patch fixes the problem by having this loop igore type units.
> fission-reread.exp is updated to test for the bug.

I didn't dive deep in the code, but from your explanation and a quick glance
at the code, that makes sense.

Simon

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-08-09 12:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-08 15:39 [PATCH] Ignore .debug_types when reading .debug_aranges Tom Tromey
2021-08-09 12:27 ` Simon Marchi

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).