public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <20141108131839.GA28913@blokker.redhat.com> (raw)
In-Reply-To: m2lhnpab55.fsf@redhat.com

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

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

             reply	other threads:[~2014-11-08 13:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-08 13:18 Mark Wielaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-11-05 16:02 Petr Machata
2014-11-05 13:29 Mark Wielaard
2014-10-30 11:47 Mark Wielaard
2014-10-10 21:45 Roland McGrath
2014-10-10 21:30 Josh Stone
2014-10-10 18:42 Roland McGrath
2014-10-06 20:29 Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141108131839.GA28913@blokker.redhat.com \
    --to=mjw@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).