search for: gdbregistrar

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 C...

Hi All, I'd like to revisit the MCJIT debugger-registration system, as the existing system has a few flaws, 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 objec...

...s.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131220/b6c61aea/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: GDBRegistrar.patch Type: text/x-diff Size: 573 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131220/b6c61aea/attachment.patch>

On Fri, Dec 20, 2013 at 11:18:46AM +0100, Andrew MacPherson wrote: > This patch forces it to leave the call using the method described here in > the 'noinline' section: Use asm volatile("":::"memory") to make sure that it doesn't leave trackes. The noinline can likely go in that case... Joerg

...>> Hi All, >> >> I'd like to revisit the MCJIT debugger-registration system, as the existing system has a few flaws, 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...

.../mailman/listinfo/llvmdev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140115/a1ea5a10/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: GDBRegistrar-2.patch Type: text/x-diff Size: 735 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140115/a1ea5a10/attachment.patch>

...t; >>>> I'd like to revisit the MCJIT debugger-registration system, as the existing system has a few flaws, 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. M...

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++

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 >