From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 698EF3987977; Fri, 23 Oct 2020 11:29:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 698EF3987977 From: "dodji at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo. Date: Fri, 23 Oct 2020 11:29:01 +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: dodji at redhat dot com X-Bugzilla-Status: ASSIGNED 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: 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 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 11:29:01 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26684 --- Comment #16 from dodji at redhat dot com --- "fche at redhat dot com" writes: > --- Comment #15 from Frank Ch. Eigler --- Thank you Frank for taking the time to reply to this! > Just some vague opinion from the backward compatibility peanut galary: > > Was the misinterpretation ambiguous / information-losing? Sadly, I am afraid it was :-( (unless I am missing something). For little endian machines, libabigail was wrongly interpreting DW_AT_bit_offset as being the same value as for big endian machines. So the resulting data member offset we were getting is wrong. And that wrong number is what's saved in the abixml file. At the abixml level, we don't save the other low level details of the bitfield layout that would help us convert that buggy data member offset into the correct one. We just save the offset of the data member and its type. Now in hindsight, I am thinking maybe I should have save some of that information ... > If not, then it does not seem necessary to do a major flag-day version > bump, because abidiff could read a v1 xml file, convert from its buggy > bit numbering scheme to the correct one. It could treat the data (or > even rewrite it) as though it were a v2 correct one. > Heck, if the buggy data is straightforward to correct in xml, could > put the correct bit# into a new-name xml element/attribute nearby, > rather than requiring a top level version bump? Yes, it would have been super cool to be able to do that ... --=20 You are receiving this mail because: You are on the CC list for the bug.=