From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 638FE395BC48; Wed,  2 Dec 2020 13:09:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 638FE395BC48
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: dwz@sourceware.org
Subject: [Bug default/26987] GCC 11 Ada binaries contain unknown tags
Date: Wed, 02 Dec 2020 13:09:45 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: dwz
X-Bugzilla-Component: default
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mark at klomp dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: nobody at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-26987-11298-Ykddudjowx@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-26987-11298@http.sourceware.org/bugzilla/>
References: <bug-26987-11298@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: dwz@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Dwz mailing list <dwz.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/dwz>,
 <mailto:dwz-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/dwz/>
List-Help: <mailto:dwz-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/dwz>,
 <mailto:dwz-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 13:09:45 -0000

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

--- Comment #9 from Mark Wielaard <mark at klomp dot org> ---
This is what eu-readelf says about the same:

 [ 54630]    subrange_type        abbrev: 32
             lower_bound          (block1)=20
              [ 0] ??? (0)
              [ 1] ??? (0)
              [ 2] ??? (0)
              [ 3] ??? (0)
              [ 4] ??? (0)
              [ 5] ??? (0)
              [ 6] ??? (0)
              [ 7] ??? (0)
              [ 8] ??? (0)
              [ 9] ??? (0)
              [10] ??? (0)
              [11] ??? (0)
              [12] ??? (0)
              [13] ??? (0)
              [14] ??? (0)
              [15] breg16  <TRUNCATED>
             upper_bound          (block1)=20
              [ 0] lo_user+0x1f
              [ 1] lo_user+0x1f
              [ 2] lo_user+0x1f
              [ 3] lo_user+0x1f
              [ 4] lo_user+0x1f
              [ 5] lo_user+0x1f
              [ 6] lo_user+0x1f
              [ 7] lo_user+0x1f
              [ 8] lo_user+0x1f
              [ 9] lo_user+0x1f
              [10] lo_user+0x1f
              [11] lo_user+0x1f
              [12] lo_user+0x1f
              [13] lo_user+0x1f
              [14] lo_user+0x1f
              [15] breg15  <TRUNCATED>
             name                 (strp)
"system__put_images__lll_integer_images__integer_typeXn"
             type                 (ref4) [ 54660]

So this is encoded as DW_FORM_block1, which is not a valid form for
DW_AT_upper_bound or DW_AT_lower_bound. According the the DWARF spec only
constant, exprloc, reference classes are.

Both readelfs and dwz seem to interpret this DW_FORM_block1 as an exprloc,
which is arguably wrong (since DWARF4 there is DW_FORM_exprloc).

In DWARF3 a DW_AT_upperbound could be represented by block, constant,
reference. But then section 2.19 said: "For a block, the value is interpret=
ed
as a DWARF expression; evaluation of the expression yields the value of the
attribute."

In DWARF5 there is DW_FORM_data16, which could be used as a constant to exp=
ress
really big constants.

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