Jack,
Do you know about
(gdb) display/i $pc
It will cause gdb to disassemble the next instruction after each single step.
The program goes bad after only 25 instructions:
Breakpoint 1, 0x0000000100ebb5b0 in pch_address_space ()
(gdb) si
0x0000000100ebb5b1 in pch_address_space ()
(gdb)
0x0000000100ebb5b4 in pch_address_space ()
(gdb)
0x0000000100ebb590 in pch_address_space ()
(gdb)
0x0000000100ebb591 in pch_address_space ()
(gdb)
0x0000000100ebb594 in pch_address_space ()
(gdb)
0x0000000100ebb59b in pch_address_space ()
(gdb)
0x0000000100ebad50 in pch_address_space ()
(gdb)
0x0000000100ebad51 in pch_address_space ()
(gdb)
0x0000000100ebad54 in pch_address_space ()
(gdb)
0x0000000100ebad58 in pch_address_space ()
(gdb)
0x0000000100ebad5c in pch_address_space ()
(gdb)
0x0000000100ebad60 in pch_address_space ()
(gdb)
0x0000000100ebb480 in pch_address_space ()
(gdb)
0x0000000100ebb481 in pch_address_space ()
(gdb)
0x0000000100ebb484 in pch_address_space ()
(gdb)
0x0000000100ebb48b in pch_address_space ()
(gdb)
0x0000000100ebb492 in pch_address_space ()
(gdb)
0x0000000100ebb496 in pch_address_space ()
(gdb)
0x0000000100ebb499 in pch_address_space ()
(gdb)
0x0000000100f5f96e in pch_address_space ()
(gdb)
0x0000000100f62356 in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f6235b in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f607d0 in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f607d7 in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f607d9 in dyld_stub___cxa_guard_release ()
(gdb)
0x00007fff8bd80878 in dyld_stub_binder ()
The call to dyld_stub_binder already has a bad parameter at this point.
To double check what image is 0x0000000100ebb499 and 0x0000000100f5f96e in ? LLVMPolly.so?
It looks like it is trying to call __cxa_guard_release (at least gdb thinks that). That is odd for the start of an initializer. There should have been a previous call to __cxa_guard_acquire.
For reference, here is stepping through hello-world:
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000100000f00 <main+0>: push %rbp
0x0000000100000f01 <main+1>: mov %rsp,%rbp
0x0000000100000f04 <main+4>: sub $0x10,%rsp
0x0000000100000f08 <main+8>: lea 0x51(%rip),%rdi # 0x100000f60
0x0000000100000f0f <main+15>: movl $0x0,-0x4(%rbp)
0x0000000100000f16 <main+22>: mov $0x0,%al
0x0000000100000f18 <main+24>: callq 0x100000f34 <dyld_stub_printf>
0x0000000100000f1d <main+29>: mov $0x0,%ecx
0x0000000100000f22 <main+34>: mov %eax,-0x8(%rbp)
0x0000000100000f25 <main+37>: mov %ecx,%eax
0x0000000100000f27 <main+39>: add $0x10,%rsp
0x0000000100000f2b <main+43>: pop %rbp
0x0000000100000f2c <main+44>: retq
End of assembler dump.
(gdb) display/i $pc
1: x/i $pc 0x100000f08 <main+8>: lea 0x51(%rip),%rdi # 0x100000f60
(gdb) si
0x0000000100000f0f in main ()
1: x/i $pc 0x100000f0f <main+15>: movl $0x0,-0x4(%rbp)
(gdb)
0x0000000100000f16 in main ()
1: x/i $pc 0x100000f16 <main+22>: mov $0x0,%al
(gdb)
0x0000000100000f18 in main ()
1: x/i $pc 0x100000f18 <main+24>: callq 0x100000f34 <dyld_stub_printf>
(gdb)
0x0000000100000f34 in dyld_stub_printf ()
1: x/i $pc 0x100000f34 <dyld_stub_printf>: jmpq *0x106(%rip) # 0x100001040
(gdb)
0x0000000100000f56 in dyld_stub_printf ()
1: x/i $pc 0x100000f56: pushq $0xc
(gdb)
0x0000000100000f5b in dyld_stub_printf ()
1: x/i $pc 0x100000f5b: jmpq 0x100000f3c
(gdb)
0x0000000100000f3c in dyld_stub_printf ()
1: x/i $pc 0x100000f3c: lea 0xed(%rip),%r11 # 0x100001030
(gdb)
0x0000000100000f43 in dyld_stub_printf ()
1: x/i $pc 0x100000f43: push %r11
(gdb)
0x0000000100000f45 in dyld_stub_printf ()
1: x/i $pc 0x100000f45: jmpq *0xdd(%rip) # 0x100001028
(gdb)
0x00007fff8e2576a0 in dyld_stub_binder ()
1: x/i $pc 0x7fff8e2576a0 <dyld_stub_binder>: push %rbp
(gdb)
The stub (PLT entry) is just a single instruction jump through a pointer ("jmpq *0x106(%rip)"). The first time used, it points to a helper the push extra parameters and jumps into dyld. In this example, the "pushq $0xc" instruction tells dyld which lazy pointer to bind. In your crashing case, the 114808 seems to have been pushed, but that is too big.
-Nick