public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "dodji at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/26943] inexplicable type changing when running abidiff
Date: Sat, 28 Nov 2020 11:11:29 +0000	[thread overview]
Message-ID: <bug-26943-9487-X1Dp5hKX6k@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-26943-9487@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=26943

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from dodji at redhat dot com ---
Just some context on this issue.

There are actually two issues here.  One is the root issue and the second is a
corollary.

The first issue is that libabigail has subtle bugs that make it either
misrepresent some characteristics of some ABI artifact when it loads them from
DWARF or forget to serialize some of those characteristics into ABIXML.

So later when the internal representation (IR) coming from the DWARF is
compared to the IR coming from the ABIXML, spurious ABI changes are reported,
due to this first issue.

In general those misrepresented characteristics don't induce ABI changes that
are considered incompatible.  Those changes are usually harmless.

The second issue is that abidw --abidiff emits an error only if comparing the
IR coming from the binary against the IR coming from its ABIXML yields
*incompatible* ABI changes.  It won't emit an error for harmless changes.

The second issue is actually by design.  I did that because until now, I didn't
fix all those little (but real) bugs that constitute the first issue.  So, for
abidw --abidff to still be useful I made the choice of having it ignore
harmless changes.  It helped us catch several "bigger" problems like crashes
and actual incompatible ABI changes that were occurring while comparing the
binary against its ABIXML representation. 

So I sat down to chase those bugs to fix the first issue.  That led me to
changing abidw --abidiff to make it complain for harmless issues as well.

This led to patches the patch set
https://sourceware.org/pipermail/libabigail/2020q4/002920.html that was apply
to master recently.

With that patch set in master, this problem is now fixed.  Meaning the two
issues described above should now be solved.  Note that 'abipkgdiff
--self-check' has also been updated to complain even for harmless changes.

Thanks for reporting this problem!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

      reply	other threads:[~2020-11-28 11:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25  1:24 [Bug default/26943] New: " woodard at redhat dot com
2020-11-28 11:11 ` dodji at redhat dot com [this message]

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=bug-26943-9487-X1Dp5hKX6k@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=libabigail@sourceware.org \
    /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).