Hello Team,
I would like to know that Is it possible to debug LLVM-clang with GDB?
If yes, please point out the steps or wiki page.
Regards,
Nadaf.
I’m not sure we have a guide anywhere, but its just like debugging any other program with GDB. Make sure you’ve built with debug symbols, and have at it. There are some tips (many things have a .dump method that prints some interesting info, and we also have some pretty-printers for gdb in llvm/utils/gdb-scripts/prettyprinters.py), but otherwise you just use GDB like normal.
yep, just like any other program/debugger
You do have to be careful about debugging the clang driver versus the
clang frontend - either run clang -### and run the resulting -cc1
command line under the debugger, or set "fork-follow-mode child" to
have the debugger follow the frontend process from the driver process.
(I usually do the former)
I don't think this is necessary anymore! We aren't forking the cc1 in a separate process anymore I think.
I don't think this is necessary anymore! We aren't forking the cc1 in a separate process anymore I think.
I /think/ that change is only on Windows - I /think/ Clang on Linux
still runs a separate driver and frontend?
Forking is disabled on all platforms by default. The cc1 invocation will run in the calling process, unless you say -fno-integrated-cc1.
However if the clang driver creates more than one job, at the moment that disables -fintegrated-cc1, as per https://reviews.llvm.org/rG9c9e46d786d0581079e5018e550cbe187a1ec219
For example:
> clang-cl /c a.cpp b.cpp c.cpp
This is mostly because we need to cleanup in-between jobs, but disabling "-disable-free" isn’t covered by tests. Something along the lines of LLD_IN_TEST needs probably be done for Clang, and then perhaps we could reconsider https://reviews.llvm.org/D74447
-----Message d'origine-----
Huh, neat - didn't realize. Saves me some steps when debugging from
now on, then. Thanks for letting me know!