[Bug default/29044] New: abidiff reporter inconsistency

[Bug default/29044] New: abidiff reporter inconsistency

[gprocida at google dot com]

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

            Bug ID: 29044
           Summary: abidiff reporter inconsistency
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: gprocida at google dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 14057
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14057&action=edit
XML inputs and abidiff outputs

Hi Dodji.

While digging into another issue, I noticed an inconsistency between whether
abidiff and abidiff --leaf-changes-only considers there to be a ABI break.

The attachment contains two Android kernel XML files. An independent check
shows that the only differences between them are whether certain types are only
declared or fully defined.

1. abidiff reports that ir_raw_handler_register's type has changed.

2. abidiff --leaf-changes-only does not.

3. abidiff --harmless results in reports of lots of cases where only-declared
vs fully-defined is considered to be a harmless change.

4. abidiff --leaf-changes-only --harmless results in a single report that
struct drm_crtc_helper_funcs has been changed, but the report doesn't reach a
root cause.

In general, the inconsistency is a bit surprising, however, I think the best
places to look at in terms of bug hunting are 1 and 4 as, ignoring
only-declared vs fully-defined issues, nothing has changed between the two
ABIs.

Regards,
Giuliano.

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

[Bug default/29044] abidiff reporter inconsistency

[dodji at redhat dot com]

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

--- Comment #1 from dodji at redhat dot com ---
Sorry to ask this again, but do you think it's possible that I get my hand on
the kernel binaries that led to these xml files?

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

[Bug default/29044] abidiff reporter inconsistency

[gprocida at google dot com]

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

--- Comment #2 from gprocida at google dot com ---
Hi.

Here's (roughly) how each XML was created.

An external developer built a kernel some time previously. abidw (likely our
version with some changes dating back to January) was used to create the XML, a
symbol list was passed and hash-based type ids were requested. abitidy (which
has not seen much recent development) post-processed this. There is a small
chance outdated tools were used. The resulting XML was committed to an AOSP
kernel branch.

A pending change (less than a week later) reached presubmit tests. The kernel
was built in a standardised environment. abidw extracted, abitidy tidied,
abidiff diffed. Both abidiff and abidiff --leaf-changes-only were run in
parallel and this is how we spotted the discrepancy. The symbol list resulted
in a 10M ABI file vs a 19M ABI file without it.

I can provide you with the second kernel. I may even be able to provide you
with the abidw, abitidy and abidiff command lines and corresponding source
commits. Bear in mind that everything would have been built with Clang.

I cannot provide you with the first kernel as we never had it. I could try to
reproduce the XML from first principles though and if I get a match provide you
with the kernel.

It will be a fair amount of work to collect all the information and files.
Perhaps I should try to reproduce the first XML file and go from there.
However, if you are not happy working with Clang or abitidy (which I can
understand), then it may not be worth the effort.

Just in case this is relevant: I've noticed that passing a symbol list to abidw
(which uses the existing symbol suppression mechanisms) results in fewer
fully-defined types in the ABI than just editing the XML output to remove
unwanted symbols. I'm tempted to open another bug. However, I'd definitely need
to send you a large vmlinux file.

Let me know if you'd like me to proceed with data gathering.

Regards,
Giuliano.

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