Clang build analysis tool using -ftime-trace

Clang Build Analyzer Build Status

Clang C/C++ build analysis tool when using Clang 9+ -ftime-trace. The -ftime-trace compiler flag (see blog post or Clang 9 release notes) can be useful to figure out what takes time during compilation of one source file. This tool helps to aggregate time trace reports from multiple compilations, and output "what took the most time" summary:

  • Which files are slowest to parse? i.e. spend time in compiler lexer/parser front-end
  • Which C++ templates took the most time to instantiate?
  • Which files are slowest to generate code for? i.e. spend time in compiler backend doing codegen and optimizations
  • Which functions are slowest to generate code for?
  • Which header files are included the most in the whole build, how much time is spent parsing them, and what are the include chains of them?

Usage

  1. Start the build capture: ClangBuildAnalyzer --start <artifacts_folder>
    This will write current timestamp in a ClangBuildAnalyzerSession.txt file under the given artifacts_folder. The artifacts folder is where the compiled object files (and time trace report files) are expected to be produced by your build.
  2. Do your build. Does not matter how; an IDE build, a makefile, a shell script, whatever. As long as it invokes Clang and passes -ftime-trace flag to the compiler (Clang 9.0 or later is required for this).
  3. Stop the build capture: ClangBuildAnalyzer --stop <artifacts_folder> <capture_file>
    This will load all Clang time trace compatible *.json files under the given artifacts_folder that were modified after --start step was done (Clang -ftime-trace produces one JSON file next to each object file), process them and store data file into a binary capture_file.
  4. Run the build analysis: ClangBuildAnalyzer --analyze <capture_file>
    This will read the capture_file produced by --stop step, calculate the slowest things and print them. If a ClangBuildAnalyzer.ini file exists in the current folder, it will be read to control how many of various things to print.

Aternatively, instead of doing --start and --stop steps, you can do ClangBuildAnalyzer --all <artifacts_folder> <capture_file> after your build; that will include all the compatible *.json files for analysis, no matter when they were produced.

Analysis Output

The analysis output will look something like this:

Analyzing build trace from 'artifacts/FullCapture.bin'...
**** Time summary:
Compilation (1761 times):
  Parsing (frontend):         5167.4 s
  Codegen & opts (backend):   7576.5 s

**** Files that took longest to parse (compiler frontend):
 19524 ms: artifacts/Modules_TLS_0.o
 18046 ms: artifacts/Editor_Src_4.o
 17026 ms: artifacts/Modules_Audio_Public_1.o
 16581 ms: artifacts/Runtime_Camera_4.o
 
**** Files that took longest to codegen (compiler backend):
145761 ms: artifacts/Modules_TLS_0.o
123048 ms: artifacts/Runtime_Core_Containers_1.o
 56975 ms: artifacts/Runtime_Testing_3.o
 52031 ms: artifacts/Tools_ShaderCompiler_1.o

**** Templates that took longest to instantiate:
 19006 ms: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::... (2665 times, avg 7 ms)
 12821 ms: std::__1::map<core::basic_string<char, core::StringStorageDefault<ch... (250 times, avg 51 ms)
  9142 ms: std::__1::map<core::basic_string<char, core::StringStorageDefault<ch... (432 times, avg 21 ms)
  8515 ms: std::__1::map<int, std::__1::pair<List<ListNode<Behaviour> > *, List... (392 times, avg 21 ms) 

**** Functions that took longest to compile:
  8710 ms: yyparse(glslang::TParseContext*) (External/ShaderCompilers/glslang/glslang/MachineIndependent/glslang_tab.cpp)
  4580 ms: LZ4HC_compress_generic_dictCtx (External/Compression/lz4/lz4hc_quarantined.c)
  4011 ms: sqlite3VdbeExec (External/sqlite/sqlite3.c)
  2737 ms: ProgressiveRuntimeManager::Update() (artifacts/Editor_Src_GI_Progressive_0.cpp)

*** Expensive headers:
136567 ms: /BuildEnvironment/MacOSX10.14.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h (included 92 times, avg 1484 ms), included via:
  CocoaObjectImages.o AppKit.h  (2033 ms)
  OSXNativeWebViewWindowHelper.o OSXNativeWebViewWindowHelper.h AppKit.h  (2007 ms)
  RenderSurfaceMetal.o RenderSurfaceMetal.h MetalSupport.h Metal.h MTLTypes.h  (2003 ms)
  OSXWebViewWindowPrivate.o AppKit.h  (1959 ms)
  ...

112344 ms: Runtime/BaseClasses/BaseObject.h (included 729 times, avg 154 ms), included via:
  PairTests.cpp TestFixtures.h  (337 ms)
  Stacktrace.cpp MonoManager.h GameManager.h EditorExtension.h  (312 ms)
  PlayerPrefs.o PlayerSettings.h GameManager.h EditorExtension.h  (301 ms)
  Animation.cpp MaterialDescription.h  (299 ms)
  ...

103856 ms: Runtime/Threads/ReadWriteLock.h (included 478 times, avg 217 ms), included via:
  DownloadHandlerAssetBundle.cpp AssetBundleManager.h  (486 ms)
  LocalizationDatabase.cpp LocalizationDatabase.h LocalizationAsset.h StringTable.h  (439 ms)
  Runtime_BaseClasses_1.o MonoUtility.h ScriptingProfiler.h  (418 ms)
  ...

Granularity and amount of most expensive things (files, functions, templates, includes) that are reported can be controlled by having an ClangBuildAnalyzer.ini file in the working directory. Take a look at ClangBuildAnalyzer.ini for an example.

Building it

  • Windows: Visual Studio 2019 solution at projects/vs2019/ClangBuildAnalyzer.sln.
  • Mac: Xcode 10.x project at projects/xcode/ClangBuildAnalyzer.xcodeproj.
  • Linux: Makefile for gcc (tested with 7.4), build with make -f projects/make/Makefile.
  • You can also use provided CMakeLists.txt, if you want to build using CMake.

Limitations

  • Does not capture anything related to linking or LTO right now.
  • May or may not scale to huge builds (I haven't tried on something ginormous like a Chrome build). However I have tried it on Unity editor build and it was not terrible.

License

License for the Clang Build Analyzer itself is Unlicense, i.e. public domain. However, the source code includes several external library source files (all under src/external), each with their own license:

Owner
Aras Pranckevičius
Code plumber at Unity
Aras Pranckevičius
Comments
  • Make --start step optional

    Make --start step optional

    More often than not, I need to analyze the whole artifacts directory. Making session start step optional means that I can achieve this goal easier and no extra files need to be created in the process.

  • Segmentation fault during --stop

    Segmentation fault during --stop

    Unfortunately, when using with our project, I get Segmentation fault (core dumped) during --stop. I could provide you with the data you need, but I don't exactly know what to attach.

    Our project is quite small - less than 100K LOC, number of files is not big either.

    I noticed in htop, that the utility starts to use a lot of RAM, maybe this could help.

  • Error no json files found on macOS 12/ LLVM clang 13

    Error no json files found on macOS 12/ LLVM clang 13

    Looking at an older issue https://github.com/aras-p/ClangBuildAnalyzer/issues/45 I'm guessing LLVM clang 13 is not identified by this tool.

    The error is

    Stopping build tracing and saving to '1'... ERROR: no clang -ftime-trace .json files found under './'.

    Clang version:

    clang version 13.0.0 Target: x86_64-apple-darwin21.2.0 Thread model: posix

    Example json file is :

    Expand
    {
        "traceEvents": [
            {
                "pid": 16764,
                "tid": 259,
                "ph": "X",
                "ts": 6343,
                "dur": 831,
                "name": "Source",
                "args": {
                    "detail": "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/sys/cdefs.h"
                }
            },
            {
                "pid": 16764,
                "tid": 259,
                "ph": "X",
                "ts": 3786,
                "dur": 242254,
                "name": "Frontend"
            },
            {
                "pid": 16764,
                "tid": 259,
                "ph": "X",
                "ts": 125,
                "dur": 258862,
                "name": "ExecuteCompiler"
            },
            {
                "pid": 16764,
                "tid": 260,
                "ph": "X",
                "ts": 0,
                "dur": 258861,
                "name": "Total ExecuteCompiler",
                "args": {
                    "count": 1,
                    "avg ms": 258
                }
            },
            {
                "pid": 16764,
                "tid": 261,
                "ph": "X",
                "ts": 0,
                "dur": 242253,
                "name": "Total Frontend",
                "args": {
                    "count": 1,
                    "avg ms": 242
                }
            },
            {
                "pid": 16764,
                "tid": 262,
                "ph": "X",
                "ts": 0,
                "dur": 217862,
                "name": "Total Source",
                "args": {
                    "count": 28,
                    "avg ms": 7
                }
            },
            {
                "pid": 16764,
                "tid": 263,
                "ph": "X",
                "ts": 0,
                "dur": 2,
                "name": "Total PerformPendingInstantiations",
                "args": {
                    "count": 1,
                    "avg ms": 0
                }
            },
            {
                "cat": "",
                "pid": 16764,
                "tid": 259,
                "ts": 0,
                "ph": "M",
                "name": "process_name",
                "args": {
                    "name": "clang"
                }
            },
            {
                "cat": "",
                "pid": 16764,
                "tid": 259,
                "ts": 0,
                "ph": "M",
                "name": "thread_name",
                "args": {
                    "name": ""
                }
            }
        ],
        "beginningOfTime": 1641965546191608
    }
    
  • Improve performance / resource usage for big codebases

    Improve performance / resource usage for big codebases

    The analyzer can't read large json files due to this code:

    diff --git a/src/main.cpp b/src/main.cpp
    index 380b26f..fdfafbc 100644
    --- a/src/main.cpp
    +++ b/src/main.cpp
    @@ -26,7 +26,7 @@ static std::string ReadFileToString(const std::string& path)
         if (!f)
             return "";
         fseek(f, 0, SEEK_END);
    -    size_t fsize = ftell(f);
    +    size_t fsize = _ftelli64(f);
         fseek(f, 0, SEEK_SET);
         std::string str;
         str.resize(fsize);
    

    Maybe it should just use memory-mapped files.

  • ../src/external/cute_files.h:427: int cf_dir_open(cf_dir_t*, const char*): Assertion `0' failed on ClangBuildAnalyzer --stop

    ../src/external/cute_files.h:427: int cf_dir_open(cf_dir_t*, const char*): Assertion `0' failed on ClangBuildAnalyzer --stop

    Recently, when trying to use ClangBuildAnalyzer to analyze a firefox build, I got the following error and assertion failure on ClangBuildAnalyzer --stop:

    ERROR: Failed to open directory (obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd): No such file or directory.
    ClangBuildAnalyzer: ../src/external/cute_files.h:427: int cf_dir_open(cf_dir_t*, const char*): Assertion `0' failed.
    

    obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd exists, but is a symbolic link to a file, not a directory:

    [[email protected] fuzzy]$ stat obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd
      File: obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd -> /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
      Size: 88              Blocks: 8          IO Block: 4096   symbolic link
    Device: fd02h/64770d    Inode: 34560445    Links: 1
    Access: (0777/lrwxrwxrwx)  Uid: ( 1000/   simon)   Gid: ( 1000/   simon)
    Context: unconfined_u:object_r:user_home_t:s0
    Access: 2020-10-21 18:42:33.948517287 +0200
    Modify: 2020-10-14 18:48:03.012265746 +0200
    Change: 2020-10-14 18:48:03.012265746 +0200
     Birth: 2020-10-14 18:48:03.012265746 +0200
    [[email protected] fuzzy]$ stat /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
      File: /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
      Size: 0               Blocks: 0          IO Block: 4096   regular empty file
    Device: fd02h/64770d    Inode: 49026953    Links: 1
    Access: (0664/-rw-rw-r--)  Uid: ( 1000/   simon)   Gid: ( 1000/   simon)
    Context: unconfined_u:object_r:user_home_t:s0
    Access: 2020-10-22 09:43:44.048022446 +0200
    Modify: 2020-10-22 09:43:34.870015064 +0200
    Change: 2020-10-22 09:43:34.870015064 +0200
     Birth: 2020-10-22 09:43:29.366010639 +0200
    
  • ERROR: no clang -ftime-trace .json files found under <dir>

    ERROR: no clang -ftime-trace .json files found under

    I am not able to get simple trace running successfully through this tool. From a freshly cloned and built tree, I run:

    # ./ClangBuildAnalyzer  --start /tmp
    Build tracing started. Do some Clang builds with '-ftime-trace', then run 'ClangBuildAnalyzer --stop /tmp <filename>' to stop tracing and save session to a file.
    # clang <various options...> -o /tmp/main.cc.o -c /tmp/main.cc -ftime-trace -ftime-report
    ls /tmp
    # ls /tmp/main*
    /tmp/main.cc.json  /tmp/main.cc.o
    # ./ClangBuildAnalyzer --stop /tmp /tmp/report
    Stopping build tracing and saving to '/tmp/report'...
    ERROR: no clang -ftime-trace .json files found under '/tmp'.
    

    Seems to find the json file and fail while parsing it (within ParseBuildEvents in the code). The clang version is 11/head, downloaded and built today. Chrome can read and display the file successfully within chrome://tracing.

    Any ideas? My apologies if I'm missing something obvious, and thank you for producing this tool and -ftime-trace. Incredibly useful.

  • Printing stats for template sets

    Printing stats for template sets

    Sometimes, you don't just want to know the most expensive instantiation of a template (i.e. tuple<int, float>), you want to know which templates as a whole are expensive (i.e. tuple). This new analysis does that.

    Example output:

    **** Template sets that took longest to instantiate: 175188 ms: std::tuple<$> (17428 times, avg 10 ms) 70354 ms: testing::internal::FunctionMocker<$>::Invoke (6166 times, avg 11 ms) 61916 ms: testing::internal::FunctionMocker<$> (4371 times, avg 14 ms) 61186 ms: testing::internal::FunctionMockerBase<$> (4017 times, avg 15 ms) 59616 ms: testing::internal::MockSpec<$> (3936 times, avg 15 ms)

    Similarly, you don't always want to know which specific function took a long time to optimize, but which collection of template functions. Example output:

    **** Function sets that took longest to compile / optimize: 16710 ms: public: static void __cdecl testing::internal::TuplePrefix<$>::ExplainMatchFailuresTo<$>(class std::tuple<$> const &, class std::tuple<$> const &, class std::basic_ostream<$> *) (6484 times, avg 2 ms) 11430 ms: private: void __thiscall testing::internal::TypedExpectation<$>::ExplainMatchResultTo(class std::tuple<$> const &, class std::basic_ostream<$> *) const (2999 times, avg 3 ms) 11161 ms: private: class testing::Action<$> const & __thiscall testing::internal::TypedExpectation<$>::GetCurrentAction(class testing::internal::FunctionMockerBase<$> const *, class std::tuple<$> const &) const (2999 times, avg 3 ms) 5071 ms: public: static bool __cdecl testing::internal::TypeParameterizedTest<$>::Register(char const *, struct testing::internal::CodeLocation, char const *, char const *, int) (999 times, avg 5 ms) 4025 ms: private: virtual class testing::internal::ExpectationBase const * __thiscall testing::internal::FunctionMockerBase<$>::UntypedFindMatchingExpectation(void const *, void const **, bool *, class std::basic_ostream<$> *, class std::basic_ostream<$> *) (2999 times, avg 1 ms)

  • Checksum mismatch

    Checksum mismatch

    I'm attempting to profile fuchsia compilations and am running into:

    Analyzing build trace from '/tmp/capture-file'...
    ERROR: corrupt input file '/tmp/capture-file' (checksum mismatch)
    

    Do you have any ways of going about debugging this? This is from a fresh ClangBuildAnalyzer checkout and there didn't seem to be any issues with building or running it. I'm able to assert that -ftime-trace is working as intended since I can see the .json files in my build. The capture file I also made is about 470 MB.

  • fix conversion warnings

    fix conversion warnings

    since add_executable is used without sources the minimum required version has to be 3.11. see: https://cmake.org/cmake/help/v3.11/release/3.11.html#commands

  • Exception on less-than operator in template argument

    Exception on less-than operator in template argument

    With code like

    template<typename T, unsigned N>
    void foo(typename std::enable_if<(N < sizeof(T)), T>::type argument) {}
    
    void bar() { foo<int, 2>(3); }
    

    the parsing in collapseName breaks down, because < and > no longer match up. Then we go into retval.append(pos, new_pos); with pos > new_pos, which causes a std::length_error to be thrown in libstdc++.

    Note that while C++11 syntax requires parantheses around comparisons in template arguments (like in the code above), they don't seem to appear in the string that we have here, which looks like std::enable_if<(2u) < (sizeof(int)), int>::type.

  • Same file is reported multiple times when relative paths are used

    Same file is reported multiple times when relative paths are used

    Here is the output I've got when analyzing one project:

    *** Expensive headers:
    4826 ms: ../../../include/common.h (included 82 times, avg 58 ms), included via:
      ...
    
    1657 ms: ../../../../include/common.h (included 28 times, avg 59 ms), included via:
      ...
    
    938 ms: ../../include/common.h (included 16 times, avg 58 ms), included via:
      ...
    
    

    This is actually the same header and in the project it is always included via

    #include "common.h"
    

    Project folder structure looks like this:

    ├ include/
    └ src/
      └ foo/
        └ bar/
          └ baz/
    

    ... with each directory having its own Makefile listing subdirectories and make is called recursively. Top-level make gets -Iinclude and down the line we get -I../include, -I../../include, etc.

    I think ClangBuildAnalyzer should report either absolute paths to files or paths relative to its working directory combining paths from *.json files and relative locations of *.json files themselves. Path fragments like <some directory>/../ should be squashed.

  • Allow collapsing non-ambiguous operator symbols

    Allow collapsing non-ambiguous operator symbols

    I have a case where I have a bunch of templated classes that have potentially expensive operator() implementations. However, due to how we collapse names, we never collapse any operators at all and we don't end up grouping these when highlight expensive template instantiation patterns. Relevant code is here:

    ...
    static std::string_view CollapseName(const std::string_view& elt)
    {
        // Parsing op<, op<<, op>, and op>> seems hard.  Just skip'm all
        if (elt.find("operator") != std::string::npos)
          return elt;
    ...
    

    I'm wondering if we can change this to only prevent collapsing if we find either 'operator<' or 'operator>' in the name so that we can surface something like this.

  • Create a folder automatically when using `--start`

    Create a folder automatically when using `--start`

    Right now, you get an error when trying to use --start with a folder name that does not exist:

    ❯ clangbuildanalyzer --start artifacts
    ERROR: failed to create session file at 'artifacts/ClangBuildAnalyzerSession.txt'.
    

    Creating a folder manually solves this, but I think it should be done automatically (ideally recursively, so that it works when multiple folders need to be created):

    ~/Documents/Git/godotengine/godot master
    ❯ mkdir artifacts                                            
    
    ~/Documents/Git/godotengine/godot master
    ❯ clangbuildanalyzer --start artifacts
    Build tracing started. Do some Clang builds with '-ftime-trace', then run 'ClangBuildAnalyzer --stop artifacts <filename>' to stop tracing and save session to a file.
    
  • crash when running --all on a very large project

    crash when running --all on a very large project

    ClangBuildAnalysis is a great tool and it has really helped me improve the build time of a large project I am working on.

    My project is so large that the code crashes when loading the json files. I believe it is running out of memory while parsing the json dom. my project has 83GB of json files. I have run ClangBuildAnalyzer on all the files and I can analyze all of them if I do it in two groups, with the 51 largest json files in one group and the other 241 files in the other group.

    While debugging, I changed the max tasks to 1 in main.cpp, hoping that parsing 1 json at a time would reduce the memory footprint. It may have gotten farther, but ClangBuildAnalyzer still crashed.

    I tried using gdb to see the crash, but the app is killed due to out of memory, instead of core dumping, so gdb didn't give me any useful information.

    I wondered if there was a memory leak or other bug in the json parsing. I manually copied the latest release of simdjson (0.9.4) into ClangBuildAnalyzer and rebuilt. I still got the same crashes.

    I am currently using clang-11. I had more luck with ClangBuildAnalyzer on this project in the past and may have been using clang-10. I wonder if clang-10 writes fewer events? I do not see any warnings about unknown events while running ClangBuildAnalyzer with clang-11.

    Could ClangBuildAnalyzer add a batch mode to support large projects? For example, I could run ClangBuildAnalyzer -all <subdirN> on the N subdirs of my build. Then, I would run ClangBuildAnalyzer --analyze with N file names instead of 1. ClangBuildAnalyzer would then read all N binary event files and concatenate all the data together before producing the statistics over the combined set of all events.

    I have studied the LoadBuildEvents() method and believe it could be possible to have it append new files to the current event and names lists, but haven't had time to do it yet, especially making the event to name index is updated correctly.

  • Need improve error handling

    Need improve error handling

    I mistakenly passed my artefacts folder path to the "--analize" arg and ClangBuildAnalyzer crashed with std::bad_alloc from BufferedReader(FILE* f) when "fsize" was calculated as 9223372036854775807. I think it's better to add some additional checks for stupid errors like this. At least need to check that path is valid and it points to a file. Also, errors handling when working with fseek, ftello64 etc is completely skipped and ftello64 even returns signed int64_t and it also wasn't checked before being implicitly cast to size_t.

  • Not working with Xcode

    Not working with Xcode

    > ~/Downloads/ClangBuildAnalyzer-mac --start clang_analyzer
    Build tracing started. Do some Clang builds with '-ftime-trace', then run 'ClangBuildAnalyzer --stop clang_analyzer <filename>' to stop tracing and save session to a file.
    
    > ~/Downloads/ClangBuildAnalyzer-mac --stop clang_analyzer clang_analyzer_report
    Stopping build tracing and saving to 'clang_analyzer_report'...
    ERROR: no .json files found under 'clang_analyzer'.
    

    macOS Catalina 10.15.5 (19F101)

    image

    ClangBuildAnalyzerTest.zip

  • MinGW support

    MinGW support

    I changed this to build with MinGW:

    diff --git a/CMakeLists.txt b/CMakeLists.txt
    index 71f708f..56223a3 100644
    --- a/CMakeLists.txt
    +++ b/CMakeLists.txt
    @@ -22,4 +22,4 @@ set(SRC
     )
     add_executable(ClangBuildAnalyzer "${SRC}")
     target_compile_features(ClangBuildAnalyzer PRIVATE cxx_std_17)
    -target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)
    +target_link_libraries(ClangBuildAnalyzer -lpthread)
    diff --git a/src/main.cpp b/src/main.cpp
    index 3ef1fc1..68e46d6 100644
    --- a/src/main.cpp
    +++ b/src/main.cpp
    @@ -96,7 +96,7 @@ static int RunStart(int argc, const char* argv[])
         return 0;
     }
     
    -#ifdef _MSC_VER
    +#ifdef _WIN32
     static time_t FiletimeToTime(const FILETIME& ft)
     {
         ULARGE_INTEGER ull;
    @@ -128,7 +128,7 @@ struct JsonFileFinder
             if (!cf_get_file_time(f->path, &mtime))
                 return;
             time_t fileModTime;
    -#ifdef _MSC_VER
    +#ifdef _WIN32
             fileModTime = FiletimeToTime(mtime.time);
     #else
             fileModTime = mtime.time;
    
Qt-oriented static code analyzer based on the Clang framework

WARNING: master is the development branch. Please use the v1.10 branch. clazy v1.11 clazy is a compiler plugin which allows clang to understand Qt sem

Jun 22, 2022
A static analysis tool that helps security researchers scan a list of Windows kernel drivers for common vulnerability patterns in drivers (CVE makers!)
A static analysis tool that helps security researchers scan a list of Windows kernel drivers for common vulnerability patterns in drivers (CVE makers!)

Driver Analyzer A static analysis tool that helps security researchers scan a list of Windows kernel drivers for common vulnerability patterns in driv

Jun 13, 2022
Pharos Static Binary Analysis Framework

Automated static analysis tools for binary programs

Jun 22, 2022
CITL's static analysis engine for native code artifacts

citl-static-analyzer Fast binary hardening analysis tooling. Building on Linux The build process varies by Linux distribution, owing to differences be

Feb 14, 2022
Analysis of Argon and Xenon Collision data to test Bardeen-Cooper-Schrieffer Approximation

Univeristy of North Carolina Wilmington Analysis of Argon and Xenon Collision data to test Bardeen-Cooper-Schrieffer Approximation. Argon Data Tree Fi

Nov 15, 2021
ELF static analysis and injection framework that parse, manipulate and camouflage ELF files.

elfspirit elfspirit is a useful program that parse, manipulate and camouflage ELF files. It provides a variety of functions, including adding or delet

Jun 15, 2022
Static analysis of C/C++ code

Cppcheck GitHub Actions Linux Build Status Windows Build Status OSS-Fuzz Coverity Scan Build Status License About the name The original name of this p

Jun 22, 2022
Tool to check C++ #include dependencies (dependency graphs created in .dot format)
Tool to check C++ #include dependencies (dependency graphs created in .dot format)

Read Me for Dependency Checker Copyright (C) 2012-2017, TomTom International BV. All rights reserved. The tool cpp-dependencies creates #include depen

Jun 1, 2022
Probabilistic Risk Analysis Tool (fault tree analysis, event tree analysis, etc.)

SCRAM SCRAM is a Command-line Risk Analysis Multi-tool. This project aims to build a command line tool for probabilistic risk analysis. SCRAM is capab

Jun 16, 2022
android analysis tools, jni trace by native hook, libc hook, write log with caller's addr in file or AndroidLog

编译方法 unix like mkdir "build" cd build cmake .. -DNDK=your_ndk_path/Android/sdk/ndk/22.0.7026061 -DANDROID_ABI=armeabi-v7a make -j8 或者使用andriod studio编

May 18, 2022
A Linux x64 tool to trace registers and memory regions.
A Linux x64 tool to trace registers and memory regions.

HellTracer Description A Linux x64 tool to trace registers and memory regions. Build the tool Clone the repository. Compile the tool with make. Add th

Feb 15, 2022
A beautiful stack trace pretty printer for C++
A beautiful stack trace pretty printer for C++

Backward-cpp Backward is a beautiful stack trace pretty printer for C++. If you are bored to see this: Backward will spice it up for you: There is not

Jun 17, 2022
Full Apex/EAC/Origin Trace Files Cleaner

Apex Cleaner Full Apex/EAC/Origin Trace Files Cleaner This is the best cleaner I've ever made. So this is a Full Apex Legends trace cleaner. Mostly my

Jun 20, 2022
Terrain Analysis Using Digital Elevation Models (TauDEM) software for hydrologic terrain analysis and channel network extraction.

TauDEM (Terrain Analysis Using Digital Elevation Models) is a suite of Digital Elevation Model (DEM) tools for the extraction and analysis of hydrolog

Jun 13, 2022
Bear is a tool that generates a compilation database for clang tooling.

ʕ·ᴥ·ʔ Build EAR Bear is a tool that generates a compilation database for clang tooling. The JSON compilation database is used in the clang project to

Jun 23, 2022
A tool for use with clang to analyze #includes in C and C++ source files

Include What You Use For more in-depth documentation, see docs. Instructions for Users "Include what you use" means this: for every symbol (type, func

Jun 21, 2022
A tool for use with clang to analyze #includes in C and C++ source files

Include What You Use For more in-depth documentation, see docs. Instructions for Users "Include what you use" means this: for every symbol (type, func

Jun 21, 2022
🚀 Kick-start your C++! A template for modern C++ projects using CMake, CI, code coverage, clang-format, reproducible dependency management and much more.
🚀 Kick-start your C++! A template for modern C++ projects using CMake, CI, code coverage, clang-format, reproducible dependency management and much more.

ModernCppStarter Setting up a new C++ project usually requires a significant amount of preparation and boilerplate code, even more so for modern C++ p

Jun 22, 2022
A template for modern C++ projects using CMake, Clang-Format, CI, unit testing and more, with support for downstream inclusion.

Modern C++ Template A quick C++ template for modern CMake projects, aimed to be an easy to use starting point. This is my personal take on such a type

Jun 20, 2022