This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld unpredictable lookup failure building shared library


On Sun, 22 Apr 2012 12:21:08 -0700
Ian Lance Taylor <iant@google.com> wrote:
> "James K. Lowden" <jklowden@schemamania.org> writes:
> >
> > It is unclear to me why the compiler would sometimes not
> > define a symbol that cannot be drawn from a library.  
> 
> I would say that the compiler is in
> error here.  The compiler is certainly permitted to refer to a symbol
> drawn from a library.  But when compiling with -fPIC, any such
> reference must not use a R_X86_64_PC32 relocation (it should use a
> R_X86_64_PLT32 relocation instead).  So the error is that compiler
> emitted a PC32 relocation when it should have emitted a PLT32
> relocation.

Excellent, thanks, that's clear.  I am now hopeful that gcc 4.7 will
not exhibit the same behavior.  

I at last understand the domain from which the term R_X86_64_PC32 is
taken (elf) and found what appears to be the authoritative
documentation:  

http://refspecs.linuxbase.org/elf/
http://refspecs.linuxbase.org/elf/x86_64-abi-0.95.pdf (cf. table 4.10)

I remember when "medium model" meant two 64 KB segments, one for code
and one for data.  Plus ça change.  

> > $ readelf -rW  ../../lib/CodeGen/Release/ShrinkWrapping.o \
> > 	| grep '_ZNSs4_Rep10_M_disposeERKSaIcE' 
> > 000000000000004e  0000013300000002
> > R_X86_64_PC32          0000000000000000
> > _ZNSs4_Rep10_M_disposeERKSaIcE
> > + fffffffffffffffc
> 
> The 0x4e is the address of the relocation.
> The readelf -r option just dumps the relocation information, and the
> relocation refers to the symbol table.  To see the entry in the symbol
> table, you need to use the readelf -s option.

For the record, readelf reports the symbol as zero:

$ readelf -sW  ../../lib/CodeGen/Release/ShrinkWrapping.o \
	| sed -Ene '/Num:|_ZNSs4_Rep10_M_disposeERKSaIcE/p' 
Num:    Value          Size Type   Bind   Vis      Ndx Name 
307: 0000000000000000     0 NOTYPE GLOBAL DEFAULT  UND
_ZNSs4_Rep10_M_disposeERKSaIcE

which I assume means "undefined" given what else I've learned here.  

Thanks again for taking the time to diagnose and explain what the
message meant in terms I can understand.  I've been programming a long
time and I've seen compiler bugs before, but always on the input side.
C++ is a big language, and the creative programmer eventually comes up
with a valid construct that doesn't parse.  This is the first time I've
seen invalid object code exit a compiler.  

Regards, 

--jkl


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]