From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4CC213858D34 for ; Wed, 6 Mar 2024 15:15:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CC213858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4CC213858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709738111; cv=none; b=fFUitGTe0aRqF1cqd4GKzFLheTkbgHgJg55HnXd+I8MLCWQvc4uc8N44TX15mxdaYTonf1un7grkxGxp3mEyM4BSM4REa3SEl2u087wn9VXS6j/zGRTUNe7q1QzTJoG96MV0SmDHbv0uzsfIIZPaw02E9crrZ3WygecZgARvMVg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709738111; c=relaxed/simple; bh=4aLjbGo1NzIikw66g4x1rDkKXUnMUO00NES2hYkHPGU=; h=DKIM-Signature:To:Subject:From:MIME-version:Message-Id:Date; b=ivO6MTDYiKlYYBfuefwvyRb35uCAQgV/OBXZF7ZhfsU0X0K5T1MQhSGFQ9Aw+CeVmdTq9EeoYZoIGMK0bKsQLck4rQUTd9TV3jHUrsZ2CXZUFWbIqzR0ONgTFlCjjb4QjU2/bjpSuYovTLVPeb3/5uVGv2fbnEOFD5UuWLCIS0k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709738108; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aQUDggS1f5jepnyQpbgaRi5BaErpDI2t4KzBRaVpXNI=; b=Gug0JEVJjfEVpKzUpOEgnEYyqZhq2FrIZ0LJ/ECMqPVdLTA6N7TZyBDfZTwgyekYIVjjHM MRhQt7BveZ/eVqQASGpXUgncR1givq78fxr5TFcPhhpG3XXs5aRL3+hlgqzP/yiSQ5F6hz 0inIye/nTaO91fijpY0aojtkNnkKy+I= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-652-sFlt9rJrNYS7-07n7emDxQ-1; Wed, 06 Mar 2024 10:15:07 -0500 X-MC-Unique: sFlt9rJrNYS7-07n7emDxQ-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-6904160e997so60195836d6.2 for ; Wed, 06 Mar 2024 07:15:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709738106; x=1710342906; h=date:message-id:content-transfer-encoding:mime-version:from :organization:gcc:subject:cc:to:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aQUDggS1f5jepnyQpbgaRi5BaErpDI2t4KzBRaVpXNI=; b=xLo3GKtGu46f5XhghhDrLY+bHvlluhL8VVjj6GzV+iiRlrcol4c9zviQPsQF7J1khI wm225ALelGjhZ1gq8lYpOHEzFSOP+1ds5b2TKJEGSpRdtIvM6zTUktKBhf11NOAI6MNQ PGWCo59lBdLiVhot9jCvihYjtRtreD6+Lsrgwot+TMf+Yo41ANBZmDASEJenAEHDTsws r3ZcxAm5aOdG+GK8hKt8CH38i8HlzuAM14SvCAHwBUlzwIxaNgK1RV0rR5By1hKutc82 jx8LAV3u9HU4dHtw+uUiPvXbDpKWvvgC9lDqf1X9riVTfXyXC9aopTu+KTbiZXPCvfEU CTQA== X-Forwarded-Encrypted: i=1; AJvYcCXL58UpCcp2PmEX8PBFm/5dLIjLBBG1lVS24N7/rW4BvIoJDX9QlCsE4ClvH88wsz3C86OFjhkg/b1KoS9sPj9+s9XJjyHGmlbO X-Gm-Message-State: AOJu0YxquDnrhAMLr02IgtiKBEXA4JbOfgvgA6pI2ZV3F1fQBNXwz1hW uKvCOq6e1gmxINdUl3a5JlIvubRFZmynMkxjAWG6r6ZAb/KDS9f52Q0BJhIEYPTSbGCtab+IWUc P+ixAjNclL1hKMSetra+HvfTT/GpH4pbjprrpcDibw8o7pqZyrZ/gYD0Tpg== X-Received: by 2002:a0c:e74d:0:b0:690:913b:6497 with SMTP id g13-20020a0ce74d000000b00690913b6497mr3046062qvn.40.1709738106510; Wed, 06 Mar 2024 07:15:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IFrHNL+kVVfYc0udNMJ8NXurvWlK75FpV/T3f0akAHrbWvUR6CV5YYkBrw+4rUXSMm6wwjuew== X-Received: by 2002:a0c:e74d:0:b0:690:913b:6497 with SMTP id g13-20020a0ce74d000000b00690913b6497mr3046043qvn.40.1709738106176; Wed, 06 Mar 2024 07:15:06 -0800 (PST) Received: from localhost (88-120-130-27.subs.proxad.net. [88.120.130.27]) by smtp.gmail.com with ESMTPSA id f26-20020a0caa9a000000b0068fa5e5c245sm7605242qvb.84.2024.03.06.07.15.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 07:15:05 -0800 (PST) Received: by localhost (Postfix, from userid 1000) id C32F3C1B7454; Wed, 6 Mar 2024 16:15:03 +0100 (CET) To: Ben Woodard Cc: Dodji Seketeli , libabigail@sourceware.org Subject: Re: [PATCH] ir, dwarf-reader: Peel const-qualifier from const this pointers X-Operating-System: AlmaLinux 9.3 Gcc: nnfolder+archive:dodji-gmail/Sent X-URL: http://www.seketeli.net/~dodji Organization: Me, myself and I From: Dodji Seketeli MIME-version: 1.0 Message-Id: <20240306151503.C32F3C1B7454@localhost> Date: Wed, 6 Mar 2024 16:15:03 +0100 (CET) X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: redhat.com Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello Ben, Ben Woodard 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