From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============1905630269915317586=="
MIME-Version: 1.0
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH] libdw: Add dwarf_peel_type. Use it in
 dwarf_aggregate_size.
Date: Sat, 08 Nov 2014 14:18:39 +0100
Message-ID: <20141108131839.GA28913@blokker.redhat.com>
In-Reply-To: m2lhnpab55.fsf@redhat.com

--===============1905630269915317586==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 05, 2014 at 05:02:30PM +0100, Petr Machata wrote:
> Mark Wielaard <mjw@redhat.com> writes:
> =

> > Is it clear what the intent of the function is?
> =

> Yes.

Thanks, I have pushed the patch to master now.

> > And when we do extend the tags that get peeled, do we need to update
> > the function symbol version?
> =

> I don't think so.  If we are adding new tags (i.e. from a new Dwarf
> version) and the additions fit into existing contract, then callers
> should benefit from the improvements without having to be rebuilt.
> =

> Adding more tags from existing versions is something of a gray area, as
> the code could easily assume a set of tags that are peeled.  I still
> lean towards not bumping.  If the contract didn't change, this is just
> bugfixing.  We really should have peeled this particular tag, as it fits
> the bill, but we forgot about it.

There could in theory also be GNU extensions that are added for older
DWARF versions (when not using -gstrict-dwarf). But it is probably not
a good idea for GCC to output them for older versions in the first place.

I agree with not having to bump the symbol version in general.
Lets go with that plan for now. We can always reconsider if we actually
do have to add new tags in the future.

Thanks,

Mark

--===============1905630269915317586==--