From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 97AEC3857C49; Tue, 29 Mar 2022 20:37:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 97AEC3857C49 From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/29008] New: abicompat doesn't consider functions (or variables) whose symbol type is NOTYPE Date: Tue, 29 Mar 2022 20:37:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: 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: Tue, 29 Mar 2022 20:37:02 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29008 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=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 . 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=