This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What does multiple DW_OP_piece mean in DWARF?
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Dan Towner <dant at picochip dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 31 Oct 2011 13:07:34 +0100
- Subject: Re: What does multiple DW_OP_piece mean in DWARF?
- References: <729c5f4f027a28b80ef044e279f9775b.squirrel@mail.picochip.co.uk>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Oct 31, 2011 at 12:01:00PM -0000, Dan Towner wrote:
> Could someone tell me whether the following sequence of DWARF information
> is correct please, and if it is, how it should be interpreted? GCC emits
> something like the following [1]:
>
> .byte 0x75 # DW_OP_breg5
> .sleb128 0
> .byte 0x93 # DW_OP_piece
> .uleb128 0x4
> .byte 0x93 # DW_OP_piece
> .uleb128 0x4
>
> Is it valid to emit two DW_OP_pieces with no separating location? My copy
Yes.
> of the spec for DWARF (v4 taken from www.dwarfstd.org) seems to suggest
> that all pieces must have a location preceeding them. There is also a
> comment in dwarf2out.c which says:
>
> "DW_OP_piece is only added if the location description expression already
> doesn't end with DW_OP_piece"
>
> so it would seem like two contiguous pieces is wrong, but it seems to
> occur so frequently I wonder if it is a correct output after all.
DW_OP_piece is preceeded by simple location description (DWARF4, 2.6.1.1).
And one of the valid simple location descriptions is empty location
description:
2.6.1.1.4 Empty Location Descriptions
An empty location description consists of a DWARF expression containing no
operations. It represents a piece or all of an object that is present in the
source but not in the object code (perhaps due to optimization).
So the above means that the first 4 bytes of the variable live in
memory pointed by register 5 and the second 4 bytes of the variable are
optimized out.
Jakub