i am using Clion 2020.3.1, and clang/llvm version 10.0.0
i want to direct libfuzzer to a specific code coverage. So i can define my own edges or decide which code is necessary to obtain.
Right now libfuzzer just counts the edges (?) or codes lines he obtains during the fuzzing.
Related
In the context of C++ toolchain, I am trying to understand the difference of the concept between cc_toolchain_suite and register_toolchains, to me it seems they achieve the same purpose: select a toolchain based on command line parameters.
See https://docs.bazel.build/versions/master/toolchains.html for register_toolchains
See https://docs.bazel.build/versions/master/cc-toolchain-config-reference.html for cc_toolchain_suite
Can someone please help understand the subtlety behind these 2 concepts?
TL;DR The cc_toolchain_suite is part of the legacy toolchain configuration system. It still exists in Bazel because the migration to the new API is not complete. The register_toolchains is part of the newer, unified toolchain API. When possible use register_toolchains instead of cc_toolchain_suite/--*crosstool_top
Originally the concept of a 'toolchain' was not standardised in Bazel, so a Java toolchain would be implemented very differently than a cc toolchain.
Before the unified starlark toolchain API, cc toolchains were specified in proto-text formatted 'CROSSTOOL' files.
With the introduction of the platforms API and the unified toolchains API, the concepts in the CROSSTOOL files were converted almost 1:1 to the new unified platforms/toolchains starlark API. This was mostly to ensure that there was compatibility between the old/new API's.
One of the concepts in the older 'CROSSTOOL' configuration system was a 'toolchain suite', that allowed you to define a group of toolchains targeting different CPU's (This was before the platforms API was introduced).
As far as I understand the only reason that cc_toolchain_suite is still a part of Bazel's starlark API is that some of the apple/android toolchains have not yet been completely migrated across.
Here are a few examples of where I've opted to using the newer register_toolchains approach. Note that these toolchains do not use cc_toolchain_suite anymore.
I'm using LLVM Code Coverage to determine the code coverage of my iOS app's source code, and after that generate a report using Slather.
I was wondering which of the criteria listed at the code coverage wikipedia, however I have trouble finding this information.
In other words; what criteria does LLVM Code Coverage Mapping Format (or Slather) use to determine the code coverage?
Thanks
LLVM Coverage is at the finer of the wikipedia list, i.e. the condition level.
For example here: http://lab.llvm.org:8080/coverage/coverage-reports/clang/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R#2/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp.html#L659
You can mouse over each side of the condition line 664 and see how many times each was evaluated.
I am trying to utilize clang tooling library for the purpose of my future tool.
What I would like to do with this tool is:
1. parse all the source code (with includes) and detect any of my keywords in the comments (comments will be some kind of interface between the programmer and my tool, which will do various things with the rest of the source code according to commands placed in the comments).
2. according to commands from the source code, do some refactoring of it
The refactoring itself will be done using clang AST, like from example below:
http://eli.thegreenplace.net/2014/07/29/ast-matchers-and-clang-refactoring-tools
The thing I am looking for currently is how to parse the comments, within the same run of clang tooling procedures. I do not want to make separate step just for parsing the source code, because it have to be already done in tooling library.
Do you know how to somehow get the information about comments included in the source code I am parsing by tooling library?
Try the options -Wdocumentation and associated options (as -fparse-all-comments). If U use some tools (as clang-check or clang-tidy, adds these options in the compile commands db.
I am working on a code base that is one half Lua and one half C++. We use Doxygen to document our C++ code.
Now, we want to use Doxygen for the Lua part, too. But Doxygen lacks support for Lua.
There is a project that kind of adds Lua support for Doxygen. It is written in Perl and I understand what it does. It implements a filter that converts a Lua source file into something that Doxygen can parse. However, Doxygen does not seem to recognize all the functions etc.
So my question really is: What is the format Doxygen expects from the filter?
The strict answer is that your filter should produce grammatically valid output in a language doxygen supports (you can use EXTENSION_MAPPING to map the file extension for your language to a supported language).
Since doxygen's parser is rather loose (it is a lexical scanner, not really a parser), it might work as well if you do not 100% follow the grammar rules of the language, but it will be a trail and error process to find out which deviations are allowed and might break if you upgrade to a future version of doxygen.
I'm looking at some code compiled for iOS in XCode (so compiled for ARM with gcc) and as far as I can see, the compiler has never used ARM's feature of allowing arbitrary instructions to have a condition attached to them, but instead always branches on a condition as would be the case on Intel and other architectures.
Is this simply a restriction of GCC (I can understand that it might be: that "condition = branch" is embedded at a too high a level in the compiler architecture to allow otherwise), or is there a particular optimisation flag that needs to be turned on to allow compilation of conditional instructions?
(Obviously I appreciate I'm making big assumptions about where use of conditional instructions "ought" to be used and would actually be an optimisation, but I have experience of programming earlier ARM chips and using and analysing the output of Acorn's original ARM C compiler, so I have a rough idea.)
Update: Having investigated this more thanks to the information below, it turns out that:
XCode compiles in Thumb-2 mode, in which conditional execution of arbitrary instructions is not available;
Under some circumstances, it does however use the ITE (if-then-else) instruction to effectively produce instructions with conditional execution.
Seeing some actual assembly would make things clear, but I suspect that the default settings for iOS compilation prefer generation of Thumb code instead of ARM for better code density. While there are pseudo-conditional instructions in Thumb32 aka Thumb-2 (supported in ARMv7 architecture via the IT instruction), the original Thumb16 only has conditional branches. Also, even in ARM mode there are some instructions that cannot be conditional (e.g. many NEON instructions use the extended opcode space with condition field set to NV).
Yes, gcc does not really produce the most optimal code WRT conditional instructions. It works well in the most simple cases, but real code suffers from some pointless slowdowns that can be avoided in hand coded arm ASM. Just to give you a rough idea, I was able to get a 2x speedup for a very low level graphics blit method by doing the read/write and copy logic in ARM asm instead of the C code emitted by gcc. But, keep in mind that this optimization is only worth it for the most heavily used parts of your code. It takes a lot of work to write well optimized ARM asm, so don't even attempt it unless there is a real benefit in the optimization.
The first thing to keep in mind is that xcode uses Thumb mode by default, so in order to generate ARM asm you will need to add the -mno-thumb option to the module specific options for the specific .c file that will contain the ARM asm. Once the ARM asm is getting emitted, you will want to conditionally compile asm statements as indicated in the answer to the following question:
ARM asm conditional compilation question