[PATCH] DWARF5 .debug_rnglists support

Jason Merrill jason@redhat.com
Mon Oct 31 21:03:00 GMT 2016


On Mon, Oct 31, 2016 at 3:33 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Oct 31, 2016 at 02:42:15PM -0400, Jason Merrill wrote:
>> On 10/20/2016 02:52 PM, Jakub Jelinek wrote:
>> >@@ -8476,7 +8498,16 @@ size_of_die (dw_die_ref die)
>> >             size += DWARF_OFFSET_SIZE;
>> >       break;
>> >     case dw_val_class_range_list:
>> >-          size += DWARF_OFFSET_SIZE;
>> >+      if (dwarf_split_debug_info
>> >+          && dwarf_version >= 5
>> >+          && a->dw_attr_val.val_entry != RELOCATED_OFFSET)
>>
>> This test, here and in value_format, should be factored out into a separate
>> function with a comment explaining why you check dwarf_split_debug_info.
>
> Ok.  Another option would be to call value_format in size_of_die
> in this case and put the comment into value_format.

That works, too.

>> In general there's a lot of code duplication between the existing ranges
>> support and the new rnglist support; even the new vector is a superset of
>> the old one.  Why duplicate the code rather than modify it?
>
> The point was to conserve memory for the -gdwarf-{2,3,4} case.
> The old table needs just 4 bytes per entry, the new one 16 bytes per entry.
> The code duplication because of that is mainly in
> add_high_low_attributes - 24 lines duplicated.

I was also thinking of the output_rnglists function.

> At least while -gdwarf-4 is the default that looked to me like acceptable
> cost, but if you disagree, I can surely try to just grow the original
> table and use it for all versions.

Please.  I think if we're going in this direction we should just go
ahead with it; if the memory consumption is going to be a problem it
would be good to find that out so we can address it.

Jason



More information about the Gcc-patches mailing list