[Bug libdw/28294] New: dwarf_aggregate_size fails on some array types

["egb.atos at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28294

            Bug ID: 28294
           Summary: dwarf_aggregate_size fails on some array types
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libdw
          Assignee: unassigned at sourceware dot org
          Reporter: egb.atos at gmail dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

In dwarf_aggregate_size.c, the helper function array_size unconditionally uses
dwarf_formsdata to obtain the value of the DW_AT_upper_bound attribute for
array types.  In many cases, this will return a negative value for C arrays
that have positive upper bounds, causing the function to return a failure
value, which propagates up through dwarf_aggregate_size.

This is an exemplary type (via readelf -w):
 <1><90e>: Abbrev Number: 37 (DW_TAG_array_type)
    <90f>   DW_AT_type        : <0x118>
 <2><913>: Abbrev Number: 11 (DW_TAG_subrange_type)
    <914>   DW_AT_type        : <0x2c>
    <918>   DW_AT_upper_bound : 249

And the same type, via eu-readelf --debug-dump=info:
 [   90e]    array_type           abbrev: 37
             type                 (ref4) [   118]
 [   913]      subrange_type        abbrev: 11
               type                 (ref4) [    2c]
               upper_bound          (data1) 249

If dwarf_aggregate_size is called on this type, when it gets the upper_bound
attribute, it will get a value of -7, and fail.  For other array sizes, this
will work.

Looking around a bit, the closest discussion I could find on the topic was this
one about signed vs unsigned interpretation of array bounds back in 2005:
http://www.dwarfstd.org/ShowIssue.php?issue=020702.1

I exchanged emails with Mark Wielaard on this, and he indicated that this did
appear to be a bug, but he wasn't sure yet where the correct fix would be.

I've tried this with a RISCV compiler (version 8.3.0), an ARM compiler (version
7.3.1) and an x86 gcc (version 7.5.0).  I've not tried it with later versions.

Here's the sample code I compiled to get the output above.  The output in the
report is from the ARM compiler.

#include <string.h>
int foofunc(int v, char *s) {
  char buff[250];
  strcpy(buff, s);
  return buff[v];
  }

int main() {
  return foofunc(4, "fdjkfd");
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.