I want to understand some parts of ‘clang' by setting debug breakpoints.
I have successfully done so with “llc” but I found that debugger breakpoints do not work for ‘clang’
The apparent cause is that the clang code is run as a child process which is created in the ‘Execute' function of ‘Program.inc'. The debugger stops fine at breakpoints set on the main thread, but breakpoints do not work for any code that is executed as the child process. I am compiling with Xcode in case this makes a difference.
Run clang with -### to get the underlying command line (the one that has the first argument “-cc1”) and then run that command under the debugger instead.
Thank you for your patience but I still don’t get it: I don’t see how that is a “command”, as it’s just a list of strings that state command options.
I know how to use the debugger, this is what I attempt to debug:
clang --target=msp430 -emit-llvm -c -S -Oz main.c
The debugger works fine, but only on the main thread. However breakpoints do not work with the code that was invoked as a child process with posix_spawn
The call to posix_spawn happens in file “Program.inc” on the ‘Execute’ function. The actual call is this
the variable Program.str() contains "/Users/joan/LLVM-9/llvm-project/build/Debug/bin/clang” at this point, which I got with a breakpoint set at that point.
HOWEVER, any code that is run under that child process is not seen by the debugger.
It’s just a ton of command line arguments, but it’s not fundamentally different from the command you were already debugging - it’s clang with some command line arguments.
This clang command (the one with the first argument of -cc1) will not invoke a child process - this is the command that the clang command you ran would run as its child process. So it’s stripping off that layer so you can debug the underlying command/child process.
Yes it is a list of strings. But the first string “/Users/joan/LLVM-9/llvm-project/build/Debug/bin/clang” is a command. The rest are arguments. So you should set your debugger to run this command:
You hit Reply on my email but then addressed David. So I want to make sure you saw my suggestion. Let me know if you tried that and/or whether or not it solved your problem.
I’m not very familiar with this macro, as it seems to be new, but looking at llvm/include/llvm/Support/Debug.h it has this comment:
// In particular, just wrap your code with the LLVM_DEBUG() macro, and it will
// be enabled automatically if you specify ‘-debug’ on the command-line.
// LLVM_DEBUG() requires the DEBUG_TYPE macro to be defined.
So, perhaps you should try adding -debug to your command line and seeing if that fixes the problem.
If that doesn’t fix it, someone else may need to help as I’m not familiar with this issue specifically.
I appreciate that. The -debug option is apparently not known in this context, this is what the console pops up immediately:
[0;1;31merror: [0munknown argument: ‘-debug’[0m Program ended with exit code: 1
I believe this is now a more general issue because all sort of output to the console is missing, not only LLVM_DEBUG() macro statements. It seems to me that I need to redirect console output to the ide console somehow. This is apparently done automatically when debugging the main thread in the usual way, but it’s not working in this case. Still, having working breakpoints and debug variables is a great improvement. So thanks for that.
Joan Lluch via llvm-dev <llvm-dev@lists.llvm.org> writes:
Hi All,
I want to understand some parts of ‘clang' by setting debug breakpoints.
I have successfully done so with “llc” but I found that debugger breakpoints do not work for ‘clang’
The apparent cause is that the clang code is run as a child process
which is created in the ‘Execute' function of ‘Program.inc'. The
debugger stops fine at breakpoints set on the main thread, but
breakpoints do not work for any code that is executed as the child
process. I am compiling with Xcode in case this makes a difference.
David provided one answer but if your debugger supports it, an easier
way is to set the debugger to follow child processes. With gdb it would
be "set follow-fork-mode child".
I have the same problem too, and I not understand what should I do to solve this problem, can you help me, here are my options when running the ‘clang’ scheme in the LLVM.xcodeproj: