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

[Zoran Zaric]

> 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