https://llvm.org/bugs/show_bug.cgi?id=26892
Bug ID: 26892
Summary: llvm-objdump -t includes reserved undefined symbol in
output, compared with GNU objdump
Product: new-bugs
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ema...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Index 0 in the symbol table is special:
> Index 0 in any symbol table is used to represent undefined symbols. This
> first entry in a symbol table is always completely zeroed. The symbol type is
> therefore STT_NOTYPE.
From
https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter6-79797/index.html
GNU objdump hides the special symbol entry:
loader.sym: file format elf64-x86-64-freebsd
SYMBOL TABLE:
000000000000a7e0 l F .text 00000000000003f9 bi_copymodules
000000000004b1f0 l O .data 000000000000002c howto_masks
...
llvm-objdump does not hide the entry:
loader.sym: file format ELF64-x86-64
SYMBOL TABLE:
0000000000000000 *UND* 00000000
000000000000a7e0 l F .text 000003f9 bi_copymodules
000000000004b1f0 l .data 0000002c howto_masks
...
Note that "readelf -s" (both GNU and ELF Tool Chain) show this symbol as well
Symbol table '.symtab' contains 1282 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 000000000000a7e0 1017 FUNC LOCAL DEFAULT 3 bi_copymodules
2: 000000000004b1f0 44 OBJECT LOCAL DEFAULT 4 howto_masks
...
I discovered this because the build process for the FreeBSD boot components
invokes objdump -t and looks for *UND* in the output in order to report failure
in case of actual unresolved syms.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
