From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5ABEE3858CDA; Wed, 20 Mar 2024 19:14:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5ABEE3858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710962048; bh=qM4RM3aQ1L3QnL7Mj0796CxcQFxcyk0NYDx4wl6BEXA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LBmSRkl0ANajI7FOHVlANKRVIZec7bkX7p+Y1uh9DVGvRCJNi9pLjSpHN5cv+SZBV 7bB6h3c6UReqwPd6sVRKDuh8j8sHy9HiQWSX+8A14Vkq0V9WOh3rO8BsFtk2VJ9A85 ZN2jg8fMLcIUMpXm/ijYK/VZ4hmPP7fGmPUoI3iM= From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/31513] abidiff differences due to change in compiler version Date: Wed, 20 Mar 2024 19:14:07 +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: WAITING 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=3D31513 Ben Woodard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |woodard at redhat dot com --- Comment #5 from Ben Woodard --- As a person who has done a lot of testing like this: Ques 1: Is this behavior expected as we have not made any change in the sou= rce files of the library the highlighted changes are in compiler source files. "is this behavior expected" is a tricky question. As a person who has done a lot of this testing. I would say that that this behavior is "expected" in t= he sense that I do not at all find it surprising. On the other hand, is this behavior "desired", no not really. Here is the thing, libabigail pulls its information from a combination of DWARF and ELF and while ELF pretty much is needed to make things work and if it isn't "right" the program doesn't run. DWARF on the other hand has been more or less an afterthought and if things were not correct then *shrug*. The feeling was it wasn't a critical problem= if debuggers didn't work perfectly in all cases. Tools such as libabigail, str= ess the DWARF in new ways and have uncovered quite a few compiler bugs over the years. We work closely with the compiler people and have resolved many issu= es as they have come up.=20 So with compilers as far apart as 7.5.0 and 11.4.0 I think it is pretty fai= r to assume that we found and fixed quite a few problems between those two relea= ses and some of the differences are false errors due to problems with the DWARF emitted by the compiler. The fact that the problems end up showing up in pa= rt of the stdlib also is suggestive that they are more a problem with DWARF th= an a problem with your library's ABI changing.=20 That being said, there may be some changes in how the templates in the head= ers that make up that part of the standard library are instantiated based on the compiler version or supported language version and this could lead to chang= es like you are seeing. If that bit of code has a conditional compilation that adds those members or deletes those other members based on the compiler's language version then you could see that. --=20 You are receiving this mail because: You are on the CC list for the bug.=