[llvm-bugs] [Bug 26892] New: llvm-objdump -t includes reserved undefined symbol in output, compared with GNU objdump

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: emaste at freebsd.org
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160309/51f72668/attachment.html>