From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E5CA13858D20; Fri, 27 Jan 2023 01:10:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E5CA13858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674781835; bh=xoSAR7PXfD5Mxs560hiTQRBzcoPqq4LWAC1li0UTi+o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XhkJEHMNS5zS4NmCnJgaImZKsnkcxcztVJ8AGQfoWxtrEbo2EJYLVJWglixEEYvAs 6CE/Nje5yDqbo/pCMJpQPR/iO2ZbpXzeXNjRtkX1aWbTwbdb3eGlYyIzweQVPMzA6O PSivwVdA2Aj2BzOR+DNLb8OS+TSmComTEPGQq5sg= From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/30048] incorrect qualifiers within compound types Date: Fri, 27 Jan 2023 01:10:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: woodard at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30048 Ben Woodard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |woodard at redhat dot com --- Comment #2 from Ben Woodard --- I would call this one of many DWARF idiom issues. At its base libabigail us= es string comparisons in many cases rather than abstractions of the semantic information. This can cause problems like this when the expression in the D= WARF is derived the source code and two literally different strings represent semantically identical items. I have filed several of these but we haven't gotten to looking at them yet. Here are some examples: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28641 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28664 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28675 I find a lot of things like this when trying to test compatibility between things which are built with different compilers.=20 Something like: abidiff lib_built_with_gcc.so same_lib_built_with_clang.so The last time that I talked to Dodji about these he suggested either fix the string comparison or putting in special case code that handles these cases after the string comparison fails. The tricky thing is really knowing what are actually ABI artifacts and what= are not. The order of restrict in relation to const doesn't matter but is the f= act that restrict included in the declaration actually an ABI artifact? It woul= dn't affect the calling convention but the codegen could be different if restrict were not included in the decl. So we don't want to just ignore restrict. Wh= at if a library added 'restrict' to an exported function's parameter. Previous users of the library may not have been expecting that requirement. Is that actually an ABI change? --=20 You are receiving this mail because: You are on the CC list for the bug.=