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
I haven’t tried that in a while. It’s possible that it has been broken. I thought there was a test for it, but I’m not seeing it right now.
A couple of suggestions to help you troubleshoot the problem:
-
Enable verbose output in GDB.
-
Set a breakpoint in MCJIT.cpp where it calls loadedObject->registerWithDebugger. Step through that and verify that it gets as far as the call to __jit_debug_register_code in GDBRegistrar.cpp.
When __jit_debug_register_code is called, you should get a message saying that GDB has loaded symbols for the dynamic code (or possibly that it couldn’t find symbols).
Let me know what happens when you do that, and I might be able to make a reasonable suggestion as to what to do next.
-Andy
Actually, put aside what I said in my previous reply for a second.
I just noticed in your output below that GDB didn’t have symbols for lli. That’s probably the heart of your problem. GDB relies on hooking a known function to get the JITed code registration to work. Since it didn’t find symbols for lli, it won’t find the hook function.
You’ll need to use a build of lli with symbols to make this work.
-Andy
I tested it with the symbols enabled for lli and it still doesn’t work. Below is the assembly for GDBJITRegistrar::registerObject containing the inlined body of NotifyDebugger. It looks like the call to __jit_debug_register_code was inlined away despite being marked with LLVM_ATTRIBUTE_NOINLINE. LLVM was compiled with the following GCC:
zdevito@derp:~/terra/tests$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Maybe the LLVM_ATTRIBUTE_NOINLINE macro is defined wrong, or the compiler is ignoring it?
Zach
That bug was fixed this January in r199350, so you may need to update LLVM.