Re: [PATCH 05/13] gdb/dwarf: few fixes for handling DW_FORM_{rng,loc}listx

Zoran Zaric via Gdb-patches
2021-01-28T15:30:40Z

> From: Simon Marchi <simon.marchi@efficios.com>
>
> We hit an assertion when loading the binary from PR 26813. When fixing
> it, execution goes a up bit further but then hits another assert, and
> another, and another. With these fours fixes, I am able to load the
> binary and get to the prompt. An error is shown (index pointing outside
> of the section), because the DW_FORM_rnglistx attribute is not read
> correctly, but that one is taken care of by the next patch.
>
> The four fixes are:
>
> - attribute::form_requires_reprocessing needs to handle forms
> DW_FORM_rnglistx and DW_FORM_loclistx, because set_unsigned_reprocess
> is called for them in read_attribute_value.
>
> - read_attribute_reprocess must call set_unsigned for them, not
> set_address. The parameter of set_address is a CORE_ADDR, meaning
> it's for program addresses. Post-reprocess, DW_FORM_rnglistx and
> DW_FORM_loclistx are offsets into their respective sections
> (.debug_rnglists and .debug_loclists). set_unsigned is the current
> attribute value setter that fits the best. But perhaps we should have
> a setter that takes a sect_offset?
>
> - read_attribute_process must call as_unsigned_reprocess instead of
> as_unsigned to get the pre-reprocess value, otherwise we hit the
> assert inside as_unsigned that makes sure the attribute doesn't need
> reprocessing.
>
> - attribute::set_unsigned needs to clear the requires_reprocessing flag,
> otherwise it stays set when reprocessing DW_FORM_rnglistx and
> DW_FORM_loclistx attributes.
>
> There's another assert that we hit once the next patch is applied, but
> since it's in the same vein as the changes in this patch, I included it
> in this patch:
>
> - attribute::form_is_unsigned must handle form DW_FORM_loclistx,
> otherwise we hit the assert when trying to call set_unsigned for an
> attribute of this form. DW_FORM_rnglistx is already handled.
>

Agreed.

I came to the same conclusion while investigating this issue, but
unfortunately, didn't have the time to figure out how to fix the
following asserts.

Zoran