public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@redhat.com>
To: Ben Woodard <woodard@redhat.com>
Cc: Dodji Seketeli <dodji@redhat.com>,  libabigail@sourceware.org
Subject: Re: [PATCH] ir, dwarf-reader: Peel const-qualifier from const this pointers
Date: Wed,  6 Mar 2024 16:15:03 +0100 (CET)	[thread overview]
Message-ID: <20240306151503.C32F3C1B7454@localhost> (raw)

Hello Ben,

Ben Woodard <woodard@redhat.com> a écrit:

> I believe that I have a bug open on that one.

Yes, there are a series of bugs of yours related to that, I think.  I
need to re-test them to see where we stand today.  A number of other
things have been fixed since then, so I might need to take another
view at the whole thing.

> Are you addressing it or did you independently find the problem?

I was looking at something else (abidb), but I had your issues in mind
too when I stumbled upon this.

> This is also something that causes false positive ABI problems between
> different toolchains.

Exactly.  This patch reduces the distance between the output of g++ and
clang, as shown by the change that the patch has on the test result
tests/data/test-diff-dwarf/test42-PR21296-clanggcc-report0.txt.


> The question for me though, is this the “right” fix? I remember
> reasoning through the DWARF and wondering if a “this” pointer really
> should be const indicating that it could be a bug in the compilers
> when it is not. This makes me wonder if peeling the const pointer is
> the right solution or if it is just expedient given the current state
> of the compilers.

That's up for debate, I would say :-) (sorry).

In all the binaries I looked at, the const qualifier is added only on
the type of the this-pointer parameter carried by the concrete inlined
instance of a member function.  The abstract instance that actually
reflects what the user code is doesn't have that const qualifier.

In other words, the const qualifier is artificially added by the
compiler to the inlined concrete instance of the function.

Ultimately, that const qualifier has no material impact on the ABI, as
far as I can tell.

So rather than having to spend energy to try and figure out where it
comes from and reason where there, I thought that stripping it off
might do as well.


I hope this explains my reasoning a bit better.

Thanks for following up.

[...]

Cheers,

-- 
		Dodji


             reply	other threads:[~2024-03-06 15:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 15:15 Dodji Seketeli [this message]
2024-03-06 15:43 ` Ben Woodard
  -- strict thread matches above, loose matches on Subject: below --
2024-03-06 13:09 [PATCH] ir,dwarf-reader: " Dodji Seketeli
2024-03-06 14:51 ` [PATCH] ir, dwarf-reader: " Ben Woodard

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=20240306151503.C32F3C1B7454@localhost \
    --to=dodji@redhat.com \
    --cc=libabigail@sourceware.org \
    --cc=woodard@redhat.com \
    /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).