Re: [PATCH 07/13] gdb/dwarf: read DW_AT_ranges value as unsigned in partial_die_info::read

[Zoran Zaric via Gdb-patches <gdb-patches@sourceware.org>]

> From: Simon Marchi <simon.marchi@efficios.com>
> 
> While writing a test for this series, I made a function
> (DW_AT_subprogram) with a DW_AT_ranges attribute using the
> DW_FORM_rnglistx form:
> 
> 0x00000012:   DW_TAG_subprogram
>                  DW_AT_name [DW_FORM_string]     ("foo")
>                  DW_AT_ranges [DW_FORM_rnglistx] (indexed (0x0) rangelist = 0x00000036
>                     [0x0000000000004000, 0x0000000000005000))
> 
> And strangely I couldn't print it:
> 
>      (gdb) p foo
>      No symbol "foo" in current context.
> 
> This is because of the `attr.constant_value (0)` in the DW_AT_ranges
> handling of partial_die_info::read.  Since DW_FORM_rnglistx is not
> recognized as a constant value by attribute::constant_value, the default
> value (0) is returned.  Down the line, this causes
> dwarf2_rnglists_process to try read a range list at offset 0 in the
> .debug_rnglists section, which is obviously wrong.  In the end, no
> symbol is created for foo because we didn't find an address range.
> 
> Use attr->as_unsigned instead.  This is what is done for the equivalent
> code in dwarf2_get_pc_bounds.  With this, GDB processes the subprogram
> DIE and we are able to print the function symbol:
> 
>      (gdb) p foo
>      $1 = {void (void)} 0x4000
> 
> Note that I didn't see an actual compiler use DW_FORM_rnglistx for a
> subprogram's range.  However, in the binary attached to PR 26813, there
> are some lexical blocks with it:
> 
> 0x0000d34a:       DW_TAG_lexical_block
>                      DW_AT_ranges [DW_FORM_rnglistx]     (indexed (0x2) rangelist = 0x000000d4
>                         [0x0000000000005db1, 0x0000000000005e36)
>                         [0x0000000000005e48, 0x0000000000005f3c)
>                         [0x0000000000006045, 0x0000000000006053))
> 
> Their ranges are read incorrectly just like the ranges of the
> subprograms.  With this patch applied, they are read correctly.
> 

Good find.

Zoran