[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range

[Jack Howarth]

On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote:
> 
> On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote:
> 
> > Nick,
> >   I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative
> > as the dyld error occurs right after...
> > 
> > (gdb)
> > llvm::sys::DynamicLibrary::getPermanentLibrary (filename=0x142903da8 "/sw/opt/llvm-3.2/lib/LLVMPolly.so", errMsg=0x7fff5fbfe6e0) at /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/lib/Support/DynamicLibrary.cpp:77
> > 77        void *handle = dlopen(filename, RTLD_LAZY|RTLD_GLOBAL);
> > (gdb)
> > Reading symbols for shared libraries ... done
> > dyld: calling initializer function 0x100eea5b0 in /sw/opt/llvm-3.2/lib/LLVMPolly.so
> 
> You need to set a break point at 0x100eea5b0 and run again until that break is hit, then start stepping.
> 
> > Are there any tricks for identifying the order that the symbols are being resolved?
> (gdb) set env DYLD_PRINT_BINDINGS 1
> will show each use of a symbol as it is bound.  This can be *a lot* of information.  
> 
> -Nick

Nick,
   If I set 'break *0x100eea5b0', I didn't get any output from DYLD_PRINT_BINDINGS being set.
However if I set the breakpoint at PluginLoader.cpp:29 which is near the loading of LLVMPolly.so,
I get...

....
dyld: weak bind: LLVMPolly.so:0x100FB3130 = libc++.1.dylib:__ZdlPv, *0x100FB3130 = 0x7FFF898BD1AB
dyld: weak bind: LLVMPolly.so:0x100FB3138 = libc++.1.dylib:__Znam, *0x100FB3138 = 0x7FFF898BD173
dyld: weak bind: LLVMPolly.so:0x100FB3140 = libc++.1.dylib:__Znwm, *0x100FB3140 = 0x7FFF898BD0DF
dyld: calling initializer function 0x100ebb5b0 in /sw/opt/llvm-3.2/lib/LLVMPolly.so
dyld: lazy symbol binding failed: fast lazy bind offset out of range (53437, max=2928) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1
dyld: fast lazy bind offset out of range (53437, max=2928) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/c

The complete log is uploaded to http://llvm.org/bugs/attachment.cgi?id=9397 of http://llvm.org/bugs/show_bug.cgi?id=14140.
I would also note the following...

1) cc1 doesn't appear to be linked against any libstdc++.

/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1:
	/sw/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.1.0)
	/sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/sw/lib/libmpc.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/sw/lib/libmpfr.4.dylib (compatibility version 6.0.0, current version 6.1.0)
	/sw/lib/gmp5/libgmp.10.dylib (compatibility version 11.0.0, current version 11.5.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

whereas libPolly.so is always linked against the system libstdc++ shared library...

/sw/opt/llvm-3.2/lib/LLVMPolly.so:
	/sw/lib/libisl.10.dylib (compatibility version 11.0.0, current version 11.0.0)
	/sw/lib/gmp5/libgmp.10.dylib (compatibility version 11.0.0, current version 11.5.0)
	/sw/lib/libcloog-isl.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)


2) The problem seems to be immune to which libstdc++ shared library that /sw/lib/gcc4.7/lib/dragonegg.so
is linked against. I have built dragonegg both with the FSF gcc-fsf-4.7 compiler to link in
the FSF libstdc++ as well with clang to use the system libstdc++. Both modes of building LLVMPolly.so
produce the same fast lazy binding failure.

Any suggestions on where to go from here in debugging this?
          Jack