[Bug default/26135] Wrong linkage name causes anonymous classes miscomparison

["dodji at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #1 from dodji at redhat dot com ---
I can reproduce the issue.  Thank you for raising it.

Based on my current understanding of the problem, I have put together the patch
that you can get from commit
https://sourceware.org/git/?p=libabigail.git;a=commit;h=7da86264ff2c0aff7ecf1c62dee9c0d64ed11798,
from the branch dodji/PR26135.

The branch can be browed at
https://sourceware.org/git/?p=libabigail.git;a=shortlog;h=refs/heads/dodji/PR26135.

Maybe you can test it in your environment and see if it addresses the problem
you were looking at?

For the curious reader, here is an explanation of the issue.

When comparing decls, the overload of the 'equals' function for
instances of decl_base compares their linkage names.  If they are
different, then the decls are generally considered different.

Class declarations (and definitions) also use the 'equals' function
referred to above.  So when two classes have different linkage names,
they are always considered different.

Now let's consider the case of an anonymous class.  It doesn't have
any user-provided name, by definition.  Libabigail does, however,
assigns it an internal name for various (internal) purposes.  That
internal name is generally ignored for the purpose of (anonymous) type
comparison.  So by design, two anonymous classes can have different
internal anonymous names and yet still happen to be equal.

The root issue in this problem report is that by default, the linkage
name of a class is set to its name.  And when that class is anonymous,
its internal name is used as its linkage name.  Oops.  That leads to
anonymous classes being wrongly considered different.

This patch fixes the issue by providing additional constructors for a
class type to avoid using the internal anonymous name as its linkage
name.

Note that the same issue is present for unions so the patch does the
a similar thing for union types.

Enums are properly handled so we don't need to do anything in that
regard.

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