[Bug default/26718] New: RFC: alias change proposals

[Bug default/26718] New: RFC: alias change proposals

[gprocida+abigail at google dot com]

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

            Bug ID: 26718
           Summary: RFC: alias change proposals
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: gprocida+abigail at google dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

libabigail has supported symbol aliases in fashion since 2014.

As far as libabigail is concerned, two symbols alias if their addresses are
equal. The traditional definition also includes symbol size, but that's
unlikely to matter.

3 issues with symbol aliases and proposals are sketched below. Proposals A and
B are small changes to make alias handling more consistent and reliable.
Proposal C is more radical and would obviate the need to do any of the others.

A. Inconsistent linked list representation

The alias chain is described as circular. However, in the case of a symbol with
no other aliases, the chain is actually a finite (length 1) singly-linked list.

This inconsistent data representation between the no-alias and some-aliases
cases makes iterating over aliases harder than it should be. It has bitten us
with an infinite loop in mm-next due to the symbol table reader changes. 

Proposal

Change the last alias to point to null, not main. All or almost all loops will
become simpler. Existing external users of get_next_alias that don't also
already check for null will crash. This may happen if they loop starting from a
known non-null successor to the main symbol and only check for return to main.

Alternative

Always have exactly one alias point to the main symbol, via next. This will
need more verbose and slightly less efficient code, than the above proposal.
Existing external users testing for main.next == null will misbehave.

B. Inconsistent choice of starting symbol

Most functions that iterate over the alias chain make the implicit assumption
they are being passed the main symbol (as they terminate at null or main).
There are, however, a few functions which get passed a non-main symbol alias.

Proposal

We should review all functions that use get_next_alias and (in all likelihood)
update all of them to always iterate from main onwards. This will affect
(improve) some XML and/or diff output where some aliases are missing.

Alternative

Add ABG_ASSERT(sym.is_main_symbol()) to all such functions and only examine the
ones where the assertion is raised during testing.

C. Are aliases relevant to ABI monitoring?

Symbol addresses are not part of the ABI/API and the fact that symbols can
share the same addresses (i.e., the same function definitions or variable
storage) does not change anything about the typed interface or ABI
compatibility.

Proposal

Simply drop alias support altogether and simplify quite a bit of code and some
of the suppression semantics. However, without knowing where the requirement to
represent aliases as part of the ABI came from, we don't know what the
downsides would be.

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