[Bug default/29013] New: abicompat doesn't consider weak symbol replacement

[Bug default/29013] New: abicompat doesn't consider weak symbol replacement

[woodard at redhat dot com]

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

            Bug ID: 29013
           Summary: abicompat doesn't consider weak symbol replacement
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: woodard at redhat dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Currently abicompat only considers undefined symbols in the application when
choosing what symbols to compare in the libraries. This doesn't take into
account weak symbol replacement. If the library replaces a symbol in the
application then that symbol must have the same ABI.

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

[Bug default/29013] abicompat doesn't consider weak symbol replacement

[woodard at redhat dot com]

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

--- Comment #1 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 14044
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14044&action=edit
one reproducer

This reproducer is more complicated than it needs to be for this case but it
was designed for a slightly different purpose
https://sourceware.org/bugzilla/show_bug.cgi?id=27208 to work around the NOTYPE
problem. Because of the structure of it the original problem with backlinks
needs to be addressed as well for this to pass.

I'll construct a simpler reproducer as soon as I have time.

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

[Bug default/29013] abicompat doesn't consider weak symbol replacement

[woodard at redhat dot com]

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

--- Comment #2 from Ben Woodard <woodard at redhat dot com> ---
An example of where this could come up is when an application overrides a weak
symbol like malloc(). Malloc is such a trivial example people are unlikely to
screw that up but the point remains the ABI of the overridden call must match
the one who overrides.

The additional logic to check weak symbols would be similar to the logic found
in tools/abicompat.cc around line 720

   722        for (elf_symbols::const_iterator i =
   723               app_corpus->get_sorted_undefined_fun_symbols().begin();
   724             i != app_corpus->get_sorted_undefined_fun_symbols().end();
   725             ++i)

There would need to be a similar iterator for weak symbols.

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

[Bug default/29013] abicompat doesn't consider weak symbol replacement

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |27019


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=27019
[Bug 27019] BUILD metabug
-- 
You are receiving this mail because:
You are on the CC list for the bug.