BFD symbols resolution error ?

2013-09-07 Thread hakril lse 
Hi,

I am working on an Elf64 parser to find symbol.
Im working on 'libc.so' and found some strange things about how
objdump/gdb resolve the PLT symbols.

Here is what I get from my own parser:
==

-
# Plt addr for 'realloc'
>>> get_symbol_addr('realloc')
'0x1f4b0'
# Got addr for 'realloc'
>>> get_symbol_addr('realloc.got')
'0x3a4028
-


Here is what objdump find:
==

0001f490 :
1f490:ff 25 82 4b 38 00jmpq   *0x384b82(%rip)  # 3a4018

# So I have differents values:
#   me   |  objdump
#  PLT :  0x1f4b0  |  0x1f490
#  GOT :  0x3a4028  |  0x3a4018


But Here is the infos from readelf about the GOT reloc :
Objdump rela.plt info :
==

# It seems to be same offset that mine.
03a4028  01e80007 R_X86_64_JUMP_SLO 0007c110 realloc + 0


Even weirder !
Info extracted from GDB:
===

 -
(gdb) info proc map
..
0x77a33000 0x77bd4000   0x1a10000x0 /usr/lib/libc-2.18.so

# Let's disas MY 'realloc' PLT entry.
(gdb) x/i 0x77a33000 + 0x1f4b0
0x77a524b0 <__tls_get_addr@plt>:jmpq   *0x384b72(%rip)
# 0x77dd7028

# __tls_get_addr : it seems I was wrong : but let's follow the GOT !
(gdb) x/gx 0x77dd7028
0x77dd7028: 0x77aaf110

# (following the GOT)
(gdb) x/i 0x77aaf110
   0x77aaf110 :push   %r15
 -

So, according to GDB, the PLT entry <__tls_get_addr@plt> resolve into .
It seems to be a bug in BFD.
If I am missing something: please tell me.


Thanks,

-- 
Clement "Hakril" Rouault

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/15938] New: --start/--end-lib renders --print-map (Archive member included because of...) useless

2013-09-07 Thread ppluzhnikov at google dot com 
http://sourceware.org/bugzilla/show_bug.cgi?id=15938

Bug ID: 15938
   Summary: --start/--end-lib renders --print-map (Archive member
included because of...) useless
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ian at airs dot com
  Reporter: ppluzhnikov at google dot com
CC: ccoutant at google dot com

When debugging linking problems, it is often useful to understand what caused a
particular file (foo.o below) to be pulled out of archive.

The --print-map output has a section which answers that, e.g.:

  Archive member included because of file (symbol)

  ./libfoo.a(foo.o) main.o (foo)

Gold (GNU gold (GNU Binutils 2.23.52.20130907) 1.11) does not print that info
when using --start-lib foo.o --end-lib

Repro steps:

cat main.c

int foo();
int main() { return foo(); }

cat foo.c
int foo() { return 42; }


gcc -c foo.c main.c
ar ruv libfoo.a foo.o

# shows why foo.o was selected:
gcc main.o -L. -lfoo -Wl,--print-map  

# does *not* show why foo.o was selected:
gcc main.o -Wl,--start-lib foo.o --Wl,--end-lib -Wl,--print-map

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils