Hi, all.
Clang is the front end of C/C++ compiler and LLVM plays the role of optimizer and backend. So how do these different stages are connected? Is there any detailed document about this?
What’s more, the code of LLVM and Clang is so huge that it is hard for me to get started. If I want to make some modifications or just wanna to debug the source code, what should I do?
I use gdb. it was convenient to check call trace as well as variables.
a great feature the gdb has but i had not found it in visual studio was,
I could call a function at a breakpoint as a gdb command.
Hi, all.
Clang is the front end of C/C++ compiler and LLVM plays the role of
optimizer and backend. So how do these different stages are connected?
They're connected by API (ie: the clang binary links in the LLVM
libraries and calls into them to do optimization/machine code/assembly
emission).
Is
there any detailed document about this?
Not really
What's more, the code of LLVM and Clang is so huge that it is hard for me to
get started. If I want to make some modifications or just wanna to debug the
source code, what should I do?
Depends what it is you want to change. I started by looking at Clang
diagnostic (warnings, errors, etc) issues - false positives (cases
where warnings are emitted but shouldn't be) were a good place to
start because I could find the code that emitted the warning
(ultimately breaking on textual printing code - printf/write/whatever
basic system call) and then work backwards through the stack trace in
a debugger (gdb, etc) to find out what context lead to emitting that
warning there and where the missing checks were.
One common hurdle to debugging clang is that clang executes another
process inside itself. Either use clang -### to get the underlying
command and debug that, or in gdb use "set fork-follow-mode child" to
make sure the debugger debugs the child process.
Depends on what you want to do exactly. For LLVM, using -print-after-all will show you the IR after each pass, which can give you an idea of what passes are run and what each pass does. Debugging an individual pass is also fairly straightforward, since the code is usually contained within a single source file.
I never use debuggers to debug the compiler itself---I just put a bunch of "dbgs() << ..." in the code to see what I want to see.
-Krzysztof