From: "woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>
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 [thread overview]
Message-ID: <bug-29008-9487@http.sourceware.org/bugzilla/> (raw)
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.
next reply other threads:[~2022-03-29 20:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 20:37 woodard at redhat dot com [this message]
2022-03-29 20:38 ` [Bug default/29008] " woodard at redhat dot com
2022-03-31 21:29 ` woodard at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-29008-9487@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=libabigail@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).