From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A328E385383C; Mon, 17 May 2021 18:14:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A328E385383C From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/27208] abicompat doesn't check back calls. Date: Mon, 17 May 2021 18:14:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: woodard at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 18:14:27 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27208 --- Comment #3 from Ben Woodard --- A much simpler manifestation of this problem is: $ abicompat -u libt1.so=20 __cxa_finalize@@GLIBC_2.2.5 $=20 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 Symbol table [30] '.symtab' contains 55 entries: 49 local symbols String table: [31] '.strtab' Num: Value Size Type Bind Vis Ndx Name 51: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UNDEF _Z8backcallPc Currently libabigail doesn't consider NOTYPE symbols so they are not includ= ed 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 approac= h 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 . To fix that problem one would have to refactor the code so that all the functions and variables used by the plugin live in another .so then both the application and the plugin would link with that. However, fixing the problem that way would make https://sourceware.org/bugzilla/show_bug.cgi?id=3D27514= much more acute. We can begin to educate users to not underlink their code but libabigail st= ill needs to be able to detect the cases where there is underlinked but ABI significant changes.=20 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 wou= ld be to look at the kind of relocation it is given:=20 $ eu-readelf -r libt1.so Relocation section [ 8] '.rela.plt' for section [20] '.got.plt' at offset 0= x4b8 contains 2 entries: Offset Type Value Addend Name 0x0000000000004018 X86_64_JUMP_SLOT 000000000000000000 +0 __cxa_finalize 0x0000000000004020 X86_64_JUMP_SLOT 000000000000000000 +0 _Z8backca= llPc 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 parse= d, 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=3Dinfo libt1.so=20 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=3Dgeneric -march=3Dx86-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" 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. This becomes an annoying problem but it needs to be solved. --=20 You are receiving this mail because: You are on the CC list for the bug.=