Using clang-check to dump a source code's AST, can be done with the following command:
$ clang-check -ast-dump file.c --
However, the output of this command will appear colorful within the terminal.
When I direct the output to a file, I'm stuck with all of the color escape codes:
$ clang-check -ast-dump file.c -- > out.txt
example:
[0;1;32mTranslationUnitDecl[0m[0;33m 0x227c5c0[0m <[0;33m<invalid sloc>[0m> [0;33m<invalid sloc>[0m
[0;34m|-[0m[0;1;32mTypedefDecl[0m[0;33m 0x227cac0[0m <[0;33m<invalid sloc>[0m> [0;33m<invalid sloc>[0m implicit[0;1;36m __int128_t[0m [0;32m'__int128'[0m
[0;34m|-[0m[0;1;32mTypedefDecl[0m[0;33m 0x227cb20[0m <[0;33m<invalid sloc>[0m> [0;33m<invalid sloc>[0m implicit[0;1;36m __uint128_t[0m [0;32m'unsigned __int128'[0m
[0;34m|-[0m[0;1;32mTypedefDecl[0m[0;33m 0x227ce70[0m <[0;33m<invalid sloc>[0m> [0;33m<invalid sloc>[0m implicit[0;1;36m __builtin_va_list[0m [0;32m'__va_list_tag [1]'[0m
...
Is there a flag to disable colors in clang-check?
I tried adding the following flag, but it did not work:
--extra-arg="--no-color-diagnostics"
You are almost correct. Try
$ clang-check -ast-dump test.c --extra-arg="-fno-color-diagnostics" --
Additionally, -fno-diagnostics-color and -fdiagnostics-color=never also seems to work
Reference: http://clang.llvm.org/docs/UsersManual.html#formatting-of-diagnostics
Related
Windows 10, Ryzen 3700x, gcc 8.1.0 (Posix, SEH-enabled)
I am building clang, llvm, and compiler-rt (the PGO tools) from source. I have downloaded the clang+llvm source for 14.0.0, and built it successfully with the following:
cmake -G "MinGW Makefiles" -DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 ../llvm
After this, I can invoke clang, and build projects, ranging from simple "Hello, World", to a much more complex one. I am able to make use of -flto, with the addition of -fuse-ld=lld.
However, if I attempt to do ANY sort of PGO building, I fail. For example, here is the minimal example to demonstrate the problem.
Andrew#Ryzen3700x MINGW64 ~/Desktop
$ cat test.c
#include <stdio.h>
int main() {
printf("Hello, World!");
return 0;
}
Andrew#Ryzen3700x MINGW64 ~/Desktop
$ clang -fprofile-instr-generate test.c
Andrew#Ryzen3700x MINGW64 ~/Desktop
$ ./a.exe
Hello, World!
Andrew#Ryzen3700x MINGW64 ~/Desktop
$ llvm-profdata merge -output=test.profdata default.profraw
warning: default.profraw: malformed instrumentation profile data
error: no profile can be merged
Andrew#Ryzen3700x MINGW64 ~/Desktop
$ llvm-profdata show default.profraw
error: default.profraw: malformed instrumentation profile data: function name is empty
I am aware of many answers to this question, and none of them seem to apply. My .profraw file is not empty.
I will note that when I installed LLVM/Clang directly (not building on my own), the PGO portions DID work. However, after many hours I could not resolve linking issues regarding -flto.
I am working on LLVM obfuscation project. I have written a llvm pass(lets say flow flattening pass) which i am running on source (test.c) with following command:
clang -emit-llvm test.c -c -o test.bc
opt -load ../../.. LLVMFlattening.so -fla <test.bc>/dev/null
But i have seen that in O-LLVM project they achieved same thing using:
clang -emit-llvm test.c -c -o test.bc -mllvm -fla
Can someone tell me what is -mllvm here and how this changed to a simple command?
-mllvm means Additional arguments to forward to LLVM's option processing. Therefore -mllvm -fla will pass -fla to the LLVM's option processing.
Clang and LLVM could run seperately. If you want clang to run llvm, and also have some options which you want llvm to aware. -mllvm is what you need.
Defautly, LLVM does not turn on all the transformation passes. With -fla, LLVM will turn on the pass registered with command line argument fla by call function RegisterPass<typename passName>.
In your command line, opt's -load option is used to load plugin. If you want to use the simple command line as expect. Your pass need to be linked into the opt binary. This could be done in the following two ways:
(Without modify the existing LLVM source tree): Add your only pass's source by adding CMakeLists.txt mentioned in this link
Directly copy your pass source code folder into <LLVM root>/lib/Transform directory. And modify the <LLVM root>/lib/Transform/CMakeLists.txt, add add_subdirectory(<pass name>) line just like others.
I'm working on O-LLVM rencently, and came into the same problem. Here is my solution:
1.add static cl::opt<bool> YOUR_FLA("fla", cl::init(false),"info...") to PassManagerBuilder.cpp
2.add function Pass *createYOUR_FLA(bool flag) in your obfuscation pass source code
3.add MPM.add(createYOUR_FLA(YOUR_FLA)); to function populateModulePassManager in PassManagerBuilder.cpp
The solution above works with my simple pass.
I am trying to get exploded graph from one of the debug checkers called
debug.ViewExplodedGraph.
So I run command
clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph someprogram.c
It run successfully, but graph file no where to be found .
Where can we see the generated file?
I guess you should build the clang yourself. Then use the debug mode 'clang', call the command. The system clang is in release mode.
I use the system clang, it outputs nothing. But I use the clang that I build, it output something.
➜ bin ./clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph ~/Desktop/clang_test/test.c
Writing '/var/folders/_6/5wkxc9p92t94vdh0kyq2qyh40000gn/T/ExprEngine-9e6797.dot'... done.
Trying 'open' program... Remember to erase graph file: /var/folders/_6/5wkxc9p92t94vdh0kyq2qyh40000gn/T/ExprEngine-9e6797.dot
Warning: viewing graph requires assertions
➜ bin clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph ~/Desktop/clang_test/test.c
Warning: viewing graph requires assertions
cd to T folder
➜ T dot -Tsvg ExprEngine-9e6797.dot -o ~/Desktop/test.svg
then use chrome open test.svg
I have a android arm64 trace:
#02 pc 00000000000c61c0 /system/lib64/libmedia.so (_ZN7android10AudioTrack16AudioTrackThread10threadLoopEv+84)
I use below command to parser the code line information:
aarch64-linux-addr2line -f -C -e symbols/system/lib64/libmedia.so 00000000000c61cc
android::Condition::wait(android::Mutex&)
/proc/self/cwd/system/core/include/utils/Condition.h:106
Obviously, wait() is a inline function so addr2line didn't find the code line in threadLoop but use the wait() code line instead.
How to get the right line number in threadLoop? I am using binutils-2.28 to build addr2line tool.
Have you tried the -i option?
-i --inlines Unwind inlined functions
I'd like to be able to use the following macro in my modules:
-ifdef(debug).
My startup script looks something like the following:
#!/bin/sh
PWD="$(pwd)"
#NAME="$(basename $PWD)"
erl -pa "$PWD/ebin" deps/*/ebin -boot start_sasl \
-name foo#127.0.0.1 \
-debug 1 \
-s $NAME \
+K true \
+P 65536
What else would need to be added so that debug is defined in my module? I need this to be dynamic so I don't have to modify source code for deployment into production. Using different startup scripts per dev/qa/prod environments is fine, but modifying source code shouldn't be necessary.
With erlc this can be done with -Ddebug. I use rebar however, and am not sure how to do it with that. I've tried adding the following to my rebar.config:
{erl_opts, [{D, "debug"}]}.
This gives the following error:
{error,
{1,
erl_parse,
"bad term"}}
The define for the compiler in rebar.config should look like this:
{erl_opts, [{d, debug}]}.
Note: the syntax is exactly the same as the compiler module's syntax: http://www.erlang.org/doc/man/compile.html
Current version of rebar (rebar version: 2 date: 20111205_155958 vcs: git 54259c5) does support compiler defines, as well.
rebar -D <defines> compile
See rebar --help for more rebar options.
ifdef is a preprocessor macro, it gets evaluated and removed at compile time -- you would have to re-compile your module with something like erlc -Ddebug module.erl to change it. add the "-P" flag if you want to see the output from the preprocessor in module.P.
to get access to the "-debug 1" argument at runtime, you can use init:get_argument(debug).
# erl -debug 1
...
1> init:get_argument(debug).
{ok,[["1"]]}
2> init:get_argument(foo).
error