Re: [PATCH] libdw: Add dwarf_peel_type. Use it in dwarf_aggregate_size.

[Mark Wielaard <mjw@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Thu, 2014-10-30 at 12:47 +0100, Mark Wielaard wrote:
> What would be the correct way to describe that future versions might add
> those to the white list of tags to be peeled? My goal really is to have
> a type peel function that user code can depend on if they need to do
> something like find the underlying return type in the backends or like
> the dwarf_aggregate_size function. So that when DWARFv5 comes out, or
> some new GNU qualifier tag is added, all the user has to do is upgrade
> to a newer elfutils that knows about those.

So how about this description for libdw.h?

+/* For type aliases and qualifier type DIEs follow the DW_AT_type
+   attribute (recursively) and return the underlying type Dwarf_Die.
+   Returns 0 when RESULT contains a Dwarf_Die (possibly equal to the
+   given DIE) that isn't a type alias or qualifier type.  Returns 1
+   when RESULT contains a type alias or qualifier Dwarf_Die that
+   couldn't be peeled further (it doesn't have a DW_TAG_type
+   attribute).  Returns -1 when an error occured.
+
+   The current DWARF specification defines one type alias tag
+   (DW_TAG_typedef) and three qualifier type tags (DW_TAG_const_type,
+   DW_TAG_volatile_type, DW_TAG_restrict_type).  A future version of
+   this function might peel other alias or qualifier type tags if a
+   future DWARF version or GNU extension defines other type aliases or
+   qualifier type tags that don't modify or change the structural
+   layout of the underlying type.  */
+extern int dwarf_peel_type (Dwarf_Die *die, Dwarf_Die *result)
+    __nonnull_attribute__ (2);

That is the only change compared to the original patch. The
implementation and test cases are the same.

Is it clear what the intent of the function is? And when we do extend
the tags that get peeled, do we need to update the function symbol
version?

Thanks,

Mark