search for: __jit_debug_descriptor

Displaying 4 results from an estimated 4 matches for "__jit_debug_descriptor".

2014 Aug 02
5
[LLVMdev] MCJIT debugger registration interface.
...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 memory object files will have had their vaddrs fixed up by the JIT to point to where each of the linked sections reside in memory. There are a couple of problems with thi...
2014 Aug 10
3
[LLVMdev] MCJIT debugger registration interface.
...t; 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 memory object files will have had their vaddrs fixed up by the JIT to point to where each of the linked sections reside in memory. >> >> There are a couple of...
2014 Aug 11
2
[LLVMdev] MCJIT debugger registration interface.
...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 memory object files will have had their vaddrs fixed up by the JIT to point to where each of the linked sections reside in memory. >>>> >>>> There...
2014 Jul 18
4
[LLVMdev] [cfe-dev] Use of Smart Pointers in LLVM Projects
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++