bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/23267] New: objdump and readelf both assume first symbol v


From: mh-sourceware at glandium dot org
Subject: [Bug binutils/23267] New: objdump and readelf both assume first symbol version is base version
Date: Thu, 07 Jun 2018 04:15:37 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=23267

            Bug ID: 23267
           Summary: objdump and readelf both assume first symbol version
                    is base version
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: mh-sourceware at glandium dot org
  Target Milestone: ---

Created attachment 11061
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11061&action=edit
foo executable

See the various outputs for the attached executable:

$ readelf -DsW foo

Symbol table of `.gnu.hash' for image:
  Num Buc:    Value          Size   Type   Bind Vis      Ndx Name
    6   1: 000000000000067a     7 FUNC    GLOBAL DEFAULT  14 foo
    7   1: 0000000000000000     0 OBJECT  GLOBAL DEFAULT ABS FOO

$ objdump -T foo

foo:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __libc_start_main
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000000000  w   D  *UND*  0000000000000000             
_ITM_registerTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000             
_ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
000000000000067a g    DF .text  0000000000000007  Base        foo
0000000000000000 g    DO *ABS*  0000000000000000  Base        FOO

$ readelf -V foo

Version symbols section '.gnu.version' contains 8 entries:
 Addr: 0000000000000408  Offset: 0x000408  Link: 4 (.dynsym)
  000:   0 (*local*)       2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   0 (*local*)    
  004:   0 (*local*)       0 (*local*)       1 (*global*)      1 (*global*)   

Version definition section '.gnu.version_d' contains 1 entry:
  Addr: 0x0000000000000418  Offset: 0x000418  Link: 5 (.dynstr)
  000000: Rev: 1  Flags: none  Index: 1  Cnt: 1  Name: FOO

Version needs section '.gnu.version_r' contains 1 entry:
 Addr: 0x0000000000000434  Offset: 0x000434  Link: 5 (.dynstr)
  000000: Version: 1  File: libc.so.6  Cnt: 1
  0x0010:   Name: GLIBC_2.2.5  Flags: none  Version: 2


It's rather unconventional that .gnu.version_d doesn't contain a definition
with Flags: BASE, but that can happen thanks to GNU gold doing weird things
(will file a separate bug for this). Anyways, the point is, symbols foo and FOO
should appear as being associated to the version FOO, not Base.

This made it more difficult than necessary to find out what gold was doing that
was weird from the output for the symbol tables, because for ld.so, those
symbols are definitely associated with version FOO.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]