For example, when compiling a simple program
clang hello_world.c
Does the clang add any options by default? Like link library, include search path or optimization flags -O0 or exploit-mitigation flags like -mlvi-cfi?
If so, how to get a full list of default options?
Yes, Clang has default options. The document is here
Related
I have a qmake project in which I cannot debug because something adds -O2 -g to the end of the compiler flags in debug mode, overriding all my debug and optimization flags. I have greped the whole project for -O2 and there is none (I removed the one I had for release). Deleting the build folder and running qmake again didn't help. I'm trying to track down what adds compiler flags, but I'm missing something.
Known things that can add compiler flags:
QMAKE_CXXFLAGS - Adds flags as given in all builds.
QMAKE_CXXFLAGS_DEBUG - Adds flags as given in debug builds.
QMAKE_CXXFLAGS_RELEASE - Adds flags as given in release builds.
CONFIG - Adds flags that are difficult to trace. CONFIG += strict_c++ and CONFIG += c++17 managed to not have my -std=c++17 overwritten, but I can't tell what other flags that adds. Also the qmake call contains CONFIG+=debug which may or may not add other flags. I can't tell from the documentation.
mkspec - In projects->build it lists the effective qmake call which includes for example -spec linux-g++ which I think includes /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++/qmake.conf which includes more files which add platform-dependent flags. Removing the spec flag didn't remove the undesired -O2 flag though. Also it works for other projects, so it's probably not the culprit.
TEMPLATE - Specifies how the project is organized. Normally it's just APP, but this one uses subdirs which may override flags as all sub projects need to have the same flags.
An ideal answer would list all ways to add compiler flags, in which order they are added, an explanation how to check what flags they add and how to change them.
What qmake does it simply produces a makefile. A generated Makefile only uses compiler flags from CXXFLAGS (plus DEFINES) and INCPATH make variables, unless you have some handcrafted rules. It is clearly viewable from a generated makefile.
And these make variables come directly from qmake vars, such as QMAKE_CXXFLAGS, DEFINES and INCLUDEPATH. (This is done internally in qmake source code; well, actually the stuff could be more complicated on some platforms, so refer to qmake source code too).
Now, QMAKE_CXXFLAGS is just a qmake's variable. So, in principle, it can be modified at any line of any qmake script. Given that these scripts depend on OS/arch/compiler/Qt build options/App options etc. your expectations of "an ideal answer" are overstretched too far.
But, roughly speaking, qmake sources its scripts in the following order (hint: see full dependency list in a generated makefile):
features/spec_pre.prf
<QMAKE-SPEC>/qmake.conf (usually includes features/qt_config.prf and a ton of Qt-related stuff)
features/spec_post.prf
features/default_pre.prf
<user project>
features/default_post.prf
all features/xxx.prf according to the final CONFIG value (note: order reversed!)
So if you miss some flag in your project, it probably originates either from default_post.prf (like release flags for release build), or from CONFIG (i.e. features/xxx.prf).
Where can I see the actual key-value pairs set in Google style? I can't find the definition in the clang repository.
They can be found in the Format.cpp file of the clang lib.
https://github.com/llvm/llvm-project/blob/04ee232ff212b6c308e2ebc7b6125892681c54ae/clang/lib/Format/Format.cpp#L660
This is the start of the LLVM style, then the following functions after it hold the other pre-defined configuration settings. If you are looking at a different version of the code base, look for the function 'getPredefinedStyle' to find the sub-calls that are used based on the style chosen.
Why is bazel still using -std=c++0x when I explicitly passed something else?
Linkopts are options given to the linker: https://docs.bazel.build/versions/master/be/c-cpp.html#cc_binary.linkopts
Have a look at this duplicate answer: https://stackoverflow.com/a/43388168/461597
For single executables you can use copts.
The question is stated in title, the main purpose is to be able to efficiently debug some runtime-version-specific or scheme-specific code.
So for example, is it possible to log the value of DEBUG in xcode's console?
EDIT:
I should rephrase the question, I understand we can use NSLog("DEBUG = %d", DEBUG); to log a macro's value (thx #rmaddy), the question should be:
Is there better way? eg. not needing to add a command and recompile just to get the value of a single macro
The question seems a little confusing because of the mention of "runtime-version-specific". Preprocessor macros are compile-time settings rather than runtime settings.
If all you need is to find the iOS predefined macros for Xcode 6, type this into the terminal:
llvm-gcc -arch armv7 -dM -E – < /dev/null | sort
(Yes, there is a single dash by itself.)
Change the -arch option to “armv6″ or “armv7″ or “armv7s” as needed.
This can probably be extended to preprocess your project's code and show all the preprocessor macros. But that will be a compile-time operation rather than run-time.
To print the values of your custom macros at runtime would require specifically writing at least some code for each macro. Macros are tricky things. They may be #defined to one value or another or not #defined at all. They might also be #defined as numbers, or #defined as text, or object literals such as NSString, NSDictionary or NSNumber or any kind of object pointer.
The C standard "stringification operator" ('#') may be of interest if you really need to print things out at run-time.
warning: #pragma once in main file
We're running our headers through clang to get a partial AST.
Is it possible to disable that warning?
Use the -Wno-pragma-once-outside-header command line argument. Consult the Clang documentation here.
I had this thing when I accidentally included a header file in compile sources (this header has #pragma once line). To fix this remove header from compile sources (and probably you need to replace it with .cpp file)
There's no -W option for "#pragma once in main file", so you can't turn it off via the usual means. (However, the Clang developers are very aware that warnings without -W options suck, and there's a general rule that new warnings always get -W options. Cleaning up the old code, unfortunately, is left as an exercise for frustrated users.)
If you don't mind shell hackery, you could always do something like this:
# This gives the warning...
clang -c myheader.h
# ...This doesn't.
echo '#include "myheader.h"' | clang -c -x c++-header -o myheader.h.gch -
The trailing -, as usual, means "read from stdin". The -x c++ tells Clang what language you're using (since it can't tell from the file extension when there is no file), and changing c++ to c++-header means that we want to produce a .gch file instead of an .o file.
The two .gch files thus produced are NOT bit-for-bit identical. I don't know enough about gch files to tell you what might be observably different about their behavior. However, since all you care about is Clang's AST, I bet you'll be fine with it. :)
Use the -w (lowercase w not uppercase W) option while compiling the source to suppress such warnings.
There are no option to control it, so just ban this warning in your code.