Jack Howarth
2012-Oct-23 19:50 UTC
[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
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. > > -NickNick, Can you clarify what I should be looking for here? I assumed you expected that I should see some symbol bindings occur immediately after the initializer function in LLVMPolly.so is called but before dyld throws the "fast lazy bind offset out of range" error message. In the http://llvm.org/bugs/attachment.cgi?id=9397, the log file for a walk with DYLD_PRINT_INITIALIZERS and DYLD_PRINT_BINDINGS set on darwin12, I only see... (gdb) llvm::sys::DynamicLibrary::getPermanentLibrary (filename=0x141328518 "/sw/opt/llvm-3.2/lib/LLVMPolly.so", errMsg=0x7fff5fbfe6d0) 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: bind: libisl.10.dylib:0x101292010 = libsystem_c.dylib:__DefaultRuneLocale, *0x101292010 = 0x7FFF7A145890 dyld: bind: libisl.10.dylib:0x101292018 = libsystem_c.dylib:___stack_chk_guard, *0x101292018 = 0x7FFF7A1474B0 .... dyld: weak bind: LLVMPolly.so:0x100FB3128 = libc++.1.dylib:__ZdaPv, *0x100FB3128 = 0x7FFF898BD1C6 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/cc1 Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007fff5fc0109d in __dyld_dyld_fatal_error () where all of the bindings from LLVMPolly.so occur before the initializer function is called. Was this behavior expected? Also, as I noted on http://llvm.org/bugs/show_bug.cgi?id=14140#c13, a static build of LLVMPolly.so on 10.6 exhibits the same dyld error. Am I correct to assume that test proves that the offending symbol can't be from libcloog-isl, libisl, libgmp or libstdc++ because, when statically linked, those symbols can't be obtained from cc1? Is it vaild to assume that the offending symbol has to be both in the binding list seen when LLVMPolly.so loads and the symbols (defined or undefined) in cc1? Any suggestions on how to proceed in debugging this would be appreciated. Jack
Jack Howarth
2012-Oct-23 20:57 UTC
[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
On Tue, Oct 23, 2012 at 01:05:04PM -0700, Nick Kledzik wrote:> On Oct 23, 2012, at 12:50 PM, Jack Howarth wrote: > > 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, > > Can you clarify what I should be looking for here? I assumed you expected that I should see some symbol > > bindings occur immediately after the initializer function in LLVMPolly.so is called but before dyld throws > > the "fast lazy bind offset out of range" error message. In the http://llvm.org/bugs/attachment.cgi?id=9397, > > the log file for a walk with DYLD_PRINT_INITIALIZERS and DYLD_PRINT_BINDINGS set on darwin12, I only see... > > > > (gdb) > > llvm::sys::DynamicLibrary::getPermanentLibrary (filename=0x141328518 "/sw/opt/llvm-3.2/lib/LLVMPolly.so", errMsg=0x7fff5fbfe6d0) 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: bind: libisl.10.dylib:0x101292010 = libsystem_c.dylib:__DefaultRuneLocale, *0x101292010 = 0x7FFF7A145890 > > dyld: bind: libisl.10.dylib:0x101292018 = libsystem_c.dylib:___stack_chk_guard, *0x101292018 = 0x7FFF7A1474B0 > > .... > > dyld: weak bind: LLVMPolly.so:0x100FB3128 = libc++.1.dylib:__ZdaPv, *0x100FB3128 = 0x7FFF898BD1C6 > > 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/cc1 > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x00007fff5fc0109d in __dyld_dyld_fatal_error () > > > > where all of the bindings from LLVMPolly.so occur before the initializer function is called. Was this behavior > > expected? > > Also, as I noted on http://llvm.org/bugs/show_bug.cgi?id=14140#c13, a static build of LLVMPolly.so on 10.6 exhibits the > > same dyld error. Am I correct to assume that test proves that the offending symbol can't be from libcloog-isl, libisl, > > libgmp or libstdc++ because, when statically linked, those symbols can't be obtained from cc1? Is it vaild to assume that the > > offending symbol has to be both in the binding list seen when LLVMPolly.so loads and the symbols (defined or undefined) > > in cc1? Any suggestions on how to proceed in debugging this would be appreciated. > > As I said before, run once to get the address of the initializer being run inside the dlopen call (0x100ebb5b0 in the case above). Set a break point there. Run again. When it stops at the break point (inside the initializer), start stepping until it crashes. You may need to step at the instruction level. > > The point of the DYLD_PRINT_BINDINGS was so you can see what pointers dyld was setting. At some point in your trace you may be jumping through one of those pointers. You can check that the value makes sense and was not stomped by something else. > > -NickNick, Can I do this without access to a debug version of dyld? Using the copy of LLVMPolly.so with isl/cloog-isl/gmp statically linked, I find that if I set the breakpoint to the address of the initializer... dyld: calling initializer function 0x100ebb3a0 in /sw/opt/llvm-3.2/lib/LLVMPolly.so dyld: lazy symbol binding failed: fast lazy bind offset out of range (114808, 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 (114808, max=2928) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 with... (gdb) break *0x100ebb3a0 Breakpoint 2 at 0x100ebb3a0 this lands me at... dyld: weak bind: LLVMPolly.so:0x1010F4BD0 = libc++.1.dylib:__Znwm, *0x1010F4BD0 = 0x7FFF898BD0DF Breakpoint 2, 0x0000000100ebb3a0 in pch_address_space () (gdb) si 0x0000000100ebb3a1 in pch_address_space () (gdb) si 0x0000000100ebb3a4 in pch_address_space () (gdb) si 0x0000000100ebb380 in pch_address_space () (gdb) si 0x0000000100ebb381 in pch_address_space () ... and on in various dyld calls. Will I really be able to get anything useful from this without a debug build of the system dyld installed? Jack> > >
Possibly Parallel Threads
- [LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
- [LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
- [LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
- [LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
- [LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range