[PATCH] binutils/dwarf: Don't print duplicate range list entries

Andrew Burgess andrew.burgess@embecosm.com
Wed Apr 29 12:42:41 GMT 2020


* Nick Clifton <nickc@redhat.com> [2020-04-29 13:21:03 +0100]:

> Hi Andrew,
> 
> > If multiple DWARF entries reference the same offset in the
> > .debug_ranges section then we will currently print duplicate range
> > lists when dumping the range information.
> 
> But isn't this something that the user might want to know ?  
> Eg they might be testing to see if these duplicate ranges exist or not.
> 
> We already have the concept of a raw .debug_line dump vs a processed
> .debug_line dump.  Perhaps we should extend this to the .debug_ranges
> section too ?

But the duplicates don't exist.

The parsing of the .debug_ranges is really driven by the use of
DW_AT_ranges within a debugging entity.  Each DW_AT_ranges stores its
offset into the debug_info objects range_list.

Then, when we print the .debug_ranges for each referenced offset we
create a range_entry structure.

Finally we sort all of the range_entry structures based on their
offset, and print them.

My assumption here is that some clever compilers "share" parts of
their range lists, so given a .debug_ranges table like this:

   OFFSET_0   START_1   END_1
   OFFSET_2   START_2   END_2
   OFFSET_4   START_3   END_3
   OFFSET_6         0       0

One DW_AT_ranges can reference offset 0, and another can reference
offset 2, and another offset 4.  We would then print this like:

      Offset   Begin    End
      OFFSET_0 START_1  END_1
      OFFSET_0 START_2  END_2
      OFFSET_0 START_3  END_3
      OFFSET_0 <End of list>
      OFFSET_2 START_2  END_2
      OFFSET_2 START_3  END_3
      OFFSET_2 <End of list>
      OFFSET_4 START_3  END_3
      OFFSET_4 <End of list>

Which makes sense I think.  However, if what you instead have is
references to offset 0, offset 2, and offset 2, then you'll see this:

      Offset   Begin    End
      OFFSET_0 START_1  END_1
      OFFSET_0 START_2  END_2
      OFFSET_0 START_3  END_3
      OFFSET_0 <End of list>
      OFFSET_2 START_2  END_2
      OFFSET_2 START_3  END_3
      OFFSET_2 <End of list>
      OFFSET_2 START_2  END_2
      OFFSET_2 START_3  END_3
      OFFSET_2 <End of list>

Yes, the duplication does reflect the duplicate references, bug given
that when we print the DW_AT_ranges, all we see is:

     DW_AT_ranges	: OFFSET_2

When the user then goes to look at the .debug_ranges section it can be
confusing to see two lists both at OFFSET_2, at least, it confused me.

I can update the commit message if you think the patch is worth while
to better explain things.  Just let me know.

Thanks,
Andrew


More information about the Binutils mailing list