[llvm-bugs] [Bug 46777] New: Symbol index in symbol table printing is not reset

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Jul 20 07:47:30 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=46777

            Bug ID: 46777
           Summary: Symbol index in symbol table printing is not reset
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-readobj
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: jh7370.2008 at my.bristol.ac.uk, llvm-bugs at lists.llvm.org

If multiple ELF objects are passed to llvm-readelf (either independently or
within an archive) when dumping symbol tables, the index of the symbols
continues incrementing across all inputs:

C:\Work\TempWork> llvm-readelf -s bar.o bar2.o

File: bar.o

Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS bar.cpp
     2: 0000000000000000     4 OBJECT  GLOBAL HIDDEN     4 bar
     3: 0000000000000000     4 OBJECT  GLOBAL HIDDEN     3 baz

File: bar2.o

Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     4: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     5: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS bar2.cpp
     6: 0000000000000000     4 OBJECT  GLOBAL HIDDEN     3 foo
     7: 0000000000000000     4 OBJECT  GLOBAL HIDDEN     4 four

This is incorrect - the "Num" column should start from 0 at the start of every
section printing (this is what GNU readelf does). The problem is the use of a
local static variable in the printSymbol function which is used to track the
index - nothing resets this for regular object files, and it only gets reset
when switching between dumping static and dynamic symbol tables.

The fix will require a little bit of refactoring, but it should be a fairly
simple thing to do.

-- 
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/20200720/e3cad5a0/attachment-0001.html>


More information about the llvm-bugs mailing list