[Bug default/29008] New: abicompat doesn't consider functions (or variables) whose symbol type is NOTYPE

[Bug default/29008] New: abicompat doesn't consider functions (or variables) whose symbol type is NOTYPE

[woodard at redhat dot com]

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

            Bug ID: 29008
           Summary: abicompat doesn't consider functions (or variables)
                    whose symbol type is NOTYPE
           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: ---

Splitting the underlink problem with NOTYPE off from 27208. They really are
separate issues.

$ abicompat -u libt1.so 
__cxa_finalize@@GLIBC_2.2.5
$ 

The symbol in libt1.so which represents the backcall is not listed amongst the
undefined symbols.

However nm does pick it up:
[ben@alien abi-2way]$ nm libt1.so | grep "U "
                 U _Z8backcallPc

The problem ends up being that libabigail doesn't consider ELF symbols that are
underlinked. In the ELF the symbols do not take on a type recognized as a
function:

$ eu-readelf -s libt1.so
<snip>

Symbol table [30] '.symtab' contains 55 entries:
 49 local symbols  String table: [31] '.strtab'
  Num:            Value   Size Type    Bind   Vis          Ndx Name
<snip>
   51: 0000000000000000      0 NOTYPE  GLOBAL DEFAULT    UNDEF _Z8backcallPc
<snip>

Currently libabigail doesn't consider NOTYPE symbols so they are not included
in the list of functions or variables returned by
get_sorted_undefined_fun_symbols() and get_sorted_undefined_var_symbols()

It could be argued that best practices would be to link everything with "-z
defs" and then this problem would be flagged. The problem with that approach is
that there are large code bases that intentionally use underlinking for
plugins. There is no real way to fully link a plugin's .so to an application
with -l <application>.

This means that libabigail needs to consider ELF symbols of NOTYPE.

One way of determining if NOTYPE symbol may be a function or a variable would
be to look at the kind of relocation it is given: 

$ eu-readelf -r libt1.so
<snip>

Relocation section [ 8] '.rela.plt' for section [20] '.got.plt' at offset 0x4b8
contains 2 entries:
  Offset              Type            Value               Addend Name
  0x0000000000004018  X86_64_JUMP_SLOT 000000000000000000      +0
__cxa_finalize
  0x0000000000004020  X86_64_JUMP_SLOT 000000000000000000      +0 _Z8backcallPc

However relocations are architecture specific and therefore all the various
kinds of relocations would need to be handled for all the various
architectures.

Another approach could be to use the DWARF to decide if a NOTYPE symbol is a
variable or a function or something else. The problem is currently all the ELF
processing is done before any DWARF is ever looked at. During that iteration
through the ELF symbols NOTYPE symbols are discarded and so they are never
considered when the DWARF is eventually read.

It was tentatively agreed upon that libabigail would need to hold onto the
NOTYPE symbols during ELF processing. Then later on when the DWARF is parsed,
the NOTYPE symbols could be sorted into functions and variables and others.

At least with current compilers there are DIEs for underlinked symbols:
]$ eu-readelf --debug-dump=info libt1.so 

DWARF section [25] '.debug_info' at offset 0x31a8:
 [Offset]
 Compilation unit at offset 0:
 Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 Unit type: compile (1)
 [     c]  compile_unit         abbrev: 1
           producer             (strp) "GNU C++17 11.1.1 20210428 (Red Hat
11.1.1-1) -mtune=generic -march=x86-64 -g"
           language             (data1) C_plus_plus_14 (33)
           name                 (line_strp) "lib1.C"
           comp_dir             (line_strp) "/home/ben/Shared/test/abi-2way"
           low_pc               (addr) +0x0000000000001109 <_Z7libcallPc>
           high_pc              (data8) 26 (+0x0000000000001123)
           stmt_list            (sec_offset) 0
 [    2e]    subprogram           abbrev: 2
             external             (flag_present) yes
             name                 (strp) "backcall"
             decl_file            (data1) lib1.C (1)
             decl_line            (data1) 1
             decl_column          (data1) 7
             linkage_name         (strp) "_Z8backcallPc"
             type                 (ref4) [    48]
             declaration          (flag_present) yes
             sibling              (ref4) [    48]
 [    42]      formal_parameter     abbrev: 3
               type                 (ref4) [    48]
 [    48]    pointer_type         abbrev: 4
             byte_size            (data1) 8
             type                 (ref4) [    4e]
 [    4e]    base_type            abbrev: 5
             byte_size            (data1) 1
             encoding             (data1) signed_char (6)
             name                 (strp) "char"
<snip>

The functions like get_sorted_undefined_fun_symbols() and
get_sorted_undefined_var_symbols() would need to merge in the NOTYPE ELF
symbols in their iterators.

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

[Bug default/29008] abicompat doesn't consider functions (or variables) whose symbol type is NOTYPE

[woodard at redhat dot com]

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

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

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

[Bug default/29008] abicompat doesn't consider functions (or variables) whose symbol type is NOTYPE

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

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

--- Comment #2 from Ben Woodard <woodard at redhat dot com> ---
The logic that needs to be added will be similar to what is 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 additional iterators that go through the symbols which
are NOTYPE in addition to the one for undefined symbols.


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.