search for: __jit_debug_register_code

...some of which are seriously problematic. The 20,000 foot overview of the existing scheme (implemented in llvm/lib/ExecutionEngine/RuntimeDyld/GDBRegistrar.cpp and friends), as I understand it, is as follows: We have two symbols in MCJIT that act as fixed points for the debugger to latch on to: __jit_debug_register_code is a no-op function that the debugger can set a breakpoint on. MCJIT will call this function to notify the debugger when an object file is loaded. __jit_debug_descriptor is the head of a C linked list data structure that contains pointers to in-memory object files. The ELF/MachO headers of the in...

I'm trying to run the example described at: http://llvm.org/docs/DebuggingJITedCode.html I followed the sample command line session (below, with versions numbers for everything), but gdb doesn't stop at the breakpoints as described. Any idea what is wrong? Thanks, Zach zdevito at derp:~/terra/tests$ > ~/clang+llvm-3.4-x86_64-unknown-ubuntu12.04/bin/clang -cc1 -O0 -g >

Hi, We switched from compiling LLVM with gcc to clang (3.3) and it appears that clang (correctly I think) optimizes away the GDBRegistrar's __jit_debug_register_code() function that's used to trigger reading debug info from JIT-ted code, breaking GDB support. This patch forces it to leave the call using the method described here in the 'noinline' section: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html Cheers, Andrew -------------- nex...

...>> The 20,000 foot overview of the existing scheme (implemented in llvm/lib/ExecutionEngine/RuntimeDyld/GDBRegistrar.cpp and friends), as I understand it, is as follows: >> >> We have two symbols in MCJIT that act as fixed points for the debugger to latch on to: >> >> __jit_debug_register_code is a no-op function that the debugger can set a breakpoint on. MCJIT will call this function to notify the debugger when an object file is loaded. >> >> __jit_debug_descriptor is the head of a C linked list data structure that contains pointers to in-memory object files. The ELF/MachO...

...ew of the existing scheme (implemented in llvm/lib/ExecutionEngine/RuntimeDyld/GDBRegistrar.cpp and friends), as I understand it, is as follows: >>>> >>>> We have two symbols in MCJIT that act as fixed points for the debugger to latch on to: >>>> >>>> __jit_debug_register_code is a no-op function that the debugger can set a breakpoint on. MCJIT will call this function to notify the debugger when an object file is loaded. >>>> >>>> __jit_debug_descriptor is the head of a C linked list data structure that contains pointers to in-memory object files...

Hi Alp, A clear place that smart pointers *shouldn't* be used are 'create' > functions. > > There's already a strong convention in the thousands of 'create' functions > across the codebase and they have the clear, well-defined behaviour of > returning a new pointer. > > We all know what to expect from these functions, much like new/delete in > C++