I'm working on a program written in C that I occasionally build with address sanitizer, basically to catch bugs. The program prints a banner in the logs when it starts up with info such as: who built it, the branch it was built on, compiler etc. I was thinking it would be nice to also spell out if the binary was built using address sanitizer. I know there's __has_feature(address_sanitizer), but that only works for clang. I tried the following simple program:
#include <stdio.h>
int main()
{
#if defined(__has_feature)
# if __has_feature(address_sanitizer)
printf ("We has ASAN!\n");
# else
printf ("We have has_feature, no ASAN!\n");
# endif
#else
printf ("We got nothing!\n");
#endif
return 0;
}
When building with gcc -Wall -g -fsanitize=address -o asan asan.c, this yields:
We got nothing!
With clang -Wall -g -fsanitize=address -o asan asan.c I get:
We has ASAN!
Is there a gcc equivalent to __has_feature?
I know there are ways to check, like the huge VSZ value for programs built with address sanitizer, just wondering if there's a compile-time define or something.
From the GCC 4.8.0 manual:
__SANITIZE_ADDRESS__
This macro is defined, with value 1, when -fsanitize=address is in use.
Related
I wanted to compile C++11 source code within Mac Terminal but failed. I tried g++ -std=c++11, g++ -std=c++0x, g++ -std=gnu++11 and g++ -std=gnu++0x but nothing worked. Terminal always read unrecognized command line option. However, g++ -std=gnu and things like that worked fine (of course C++11 source code could not pass).
Which option should I use to turn on C++11 support?
By the way, the command line tool I'm using is installed within Xcode, and I'm pretty sure that they are up-to-date.
As others have pointed out you should use clang++ rather than g++. Also, you should use the libc++ library instead of the default libstdc++; The included version of libstdc++ is quite old and therefore does not include C++11 library features.
clang++ -std=c++11 -stdlib=libc++ -Weverything main.cpp
If you haven't installed the command line tools for Xcode you can run the compiler and other tools without doing that by using the xcrun tool.
xcrun clang++ -std=c++11 -stdlib=libc++ -Weverything main.cpp
Also if there's a particular warning you want to disable you can pass additional flags to the compiler to do so. At the end of the warning messages it shows you the most specific flag that would enable the warning. To disable that warning you prepend no- to the warning name.
For example you probably don't want the c++98 compatibility warnings. At the end of those warnings it shows the flag -Wc++98-compat and to disable them you pass -Wno-c++98-compat.
XCode uses clang and clang++ when compiling, not g++ (assuming you haven't customized things). Instead, try:
$ cat t.cpp
#include <iostream>
int main()
{
int* p = nullptr;
std::cout << p << std::endl;
}
$ clang++ -std=c++11 -stdlib=libc++ t.cpp
$ ./a.out
0x0
Thanks to bames53's answer for pointing out that I had left out -stdlib=libc++.
If you want to use some GNU extensions (and also use C++11), you can use -std=gnu++11 instead of -std=c++11, which will turn on C++11 mode and also keep GNU extensions enabled.
If I compile a simple program (sample.cpp):
#include <cstdio>
int main() {
printf("Hello, World");
return 0;
}
with a shared sanitizer library, i.e.
clang++-12 -fsanitize=address -shared-libsan sample.cpp -o sample
I am getting the following error when running ./sample:
./sample: error while loading shared libraries: libclang_rt.asan-x86_64.so: cannot open shared object file: No such file or directory
I am getting this error for the sample code on my local machine (Ubuntu 20.04 and clang-12), as well as our build runner (Ubuntu 18.04 and clang-10).
Am I missing something, or shall I submit a bug and to whom? (The options I see are Ubuntu or LLVM/Clang teams)
Please note that this question is distinct from the one that was suggested as duplicate in close votes (this was confirmed by the linked question author in comments).
This is a deficiency of the clang front-end -- when given -shared-libsan flag, it should automatically add -Wl,-rpath=/usr/lib/llvm-NN/lib/clang/MM.M.M/lib/linux to the link line, but it doesn't.
You could do that yourself by using e.g.
CXX=clang++-12
$CXX -fsanitize=address -shared-libsan sample.cpp -o sample \
-Wl,-rpath=$(dirname $($CXX --print-file-name libclang_rt.asan-x86_64.so))
Running the following code with clang++ -S -emit-llvm main.cpp && lli main.ll on Linux(Debian)
#include <future>
int main () {
return std::async([]{return 1;}).get();
}
fails to run on lli due to the following error:
LLVM ERROR: Cannot select: 0xd012e0:
i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8** #_ZSt15__once_callable> 0 [TF=10]
0xd020c0: i64 = TargetGlobalTLSAddress<i8** #_ZSt15__once_callable> 0 [TF=10]
In function: _ZSt9call_onceIMNSt13__future_base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
Questions:
What does it mean?
Are there any compiler-flags that fix this problem?
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
EDIT:
The motivation behind this question is to understand the differences between libc++ and libstdc++ that leads to this specific error message (on Linux) in llvm's orcjit.
On OSX gcc has been deprecated and clang uses by default libc++.
To reproduce this error on OSX you probably have to install gcc & use -stdlib=libstdc++.
Here is the llvm-ir (it's unfortunately to big to embed it here directly)
EDIT:
The error turned out to be caused by the lack of TLS support in the JITer. This answer describes another problem concerned with linking and lli.
If you have a look at the generated IR from clang++ -std=c++11 -S -emit-llvm test.cpp, you will find that many of the symbols, e.g. _ZNSt6futureIiE3getEv, are only declared, but never defined. The linker is never called, since -S "Only run[s] preprocess and compilation steps" (clang --help).
lli only executes the IR Module and does no "implicit" linking, how is it supposed to know which libraries to link in?
There are different solutions to this, depending on why you are using lli:
compile and link the IR Module: llc main.cpp && clang++ -lpthread main.s (pthread is required s. What is the correct link options to use std::thread in GCC under linux?)
(unconfirmed) use LD_PRELOAD="x.so y.so" to force-load the libraries before running lli
JIT the module programmatically and use LoadLibraryPermanently(nullptr) (adds symbols of the program into the search space) and LoadLibraryPermanently(file, err) for additional libs (s. http://llvm.org/docs/doxygen/html/classllvm_1_1sys_1_1DynamicLibrary.html)
I can only guess as to why libc++ works for you since it fails on my machine, but presumably it's the case because it is loaded into lli already and lli calls sys::DynamicLibrary::LoadLibraryPermanently(nullptr) to add the program's symbols to its JIT search space (s. https://github.com/llvm-mirror/llvm/blob/release_40/tools/lli/OrcLazyJIT.cpp#L110).
The LLVM-dev mailinglist pointed out:
What does it mean?
The llvm-backend in orcjit does currently not support thread-local storage(TLS)
a minimal example is:
extern thread_local int tls;
int main() {
tls = 42;
return 0;
}
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
this works because libc++ future::get implementation does not use thread_local keyword.
Are there any compiler-flags that fix this problem?
currently there is no solution.
Using lli -relocation-model=pic trades this problem with a relocation failure.
I am trying to compile a simple C++ program using g++ 4.8.2 using CMake 2.8.12.2 which makes use of C++11 features and also multithreading. For that, compiler flags -std=c++11 and -pthread must be used. From my understanding, in CMake, setting these flags can be done in various ways, one is to use the set command:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread")
The other (supposedly preferred) way is to use add_compile_options command:
add_compile_options(-std=c++11)
add_compile_options(-pthread)
(Or in one line: add_compile_options(-std=c++11 -pthread))
So, the problem is that in my case, only the first method works - by using the set command. The problem is with using the add_compile_options which results in crash of the compiled output executable with the following message (just like the -pthread was not specified at all):
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)
The code I test with:
#include <future>
int main()
{
auto a = std::async(std::launch::async, [](){});
a.wait();
return 0;
}
From the fact that this program compiles, I can infer that -std=c++11 was applied. The question is that why -pthread is not applied?
Assuming that you are definitely compiling with g++ (just worth clarifying by checking what /usr/bin/c++ actually is - I'm presuming it's a link to g++) The man page for g++ gives:
gcc [-c|-S|-E] [-std=standard]
[-g] [-pg] [-Olevel]
[-Wwarn...] [-pedantic]
[-Idir...] [-Ldir...]
[-Dmacro[=defn]...] [-Umacro]
[-foption...] [-mmachine-option...]
[-o outfile] [#file] infile...
which implies that you need to have:
g++ -std=c++11 -g -pthread ...
in that order.
Perhaps it's worth trying running your command line manually with this adjustment to see if what's produced works as you'd expect.
It looks to me (without any research, I'd add) that add_compile_options might only be useful for adding strict compiler options, so you might have to use set to set -std=c++11 and add_compile_options for all other compiler options - i.e. specified after -g
Try the following:
set (
CMAKE_CXX_FLAGS
"${CMAKE_CXX_FLAGS} "
"-Wall -Werror -pthread -std=c++11 -Wl,--no-as-needed"
)
source: here
GoogleTest 1.6 with Cygwin 1.7: 'fileno' was not declared in this scope
Error message when building a simple test on Factorial() function in Eclipse CDT:
Invoking: Cygwin C++ Compiler
g++ -std=c++0x -DGTEST_OS_CYGWIN=1 -I"E:\source\gtest-1.6.0\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/challenge.d" -MT"src/challenge.d" -o "src/challenge.o" "../src/challenge.cpp"
In file included from E:\source\gtest-1.6.0\include/gtest/internal/gtest-internal.h:40:0,
from E:\source\gtest-1.6.0\include/gtest/gtest.h:57,
from ../src/challenge.cpp:11:
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h: In function 'int testing::internal::posix::FileNo(FILE*)':
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1589:51: error: 'fileno' was not declared in this scope
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1595:57: error: 'strdup' was not declared in this scope
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1627:71: error: 'fdopen' was not declared in this scope
Eclipse CDT 8.1 running gcc 4.7.3 on Cygwin 1.7.22
gTest 1.6 succesfully built including demo tests, with cmake 2.8.9 on Cygwin 1.7.22
I've linked the built lib with full path, E:\lib\gtest-1.6.0\Cygwin\libgtest.a
The following command option was added manually, got same error without it.
-DGTEST_OS_CYGWIN=1
Seems the errors have nothing to do with my code. Anyone using gTest with Eclipse and Cygwin?
Thank you,
unsigned long Factorial(unsigned n) {
return n==0? 0 : n*Factorial(n-1);
}
// Tests factorial of 0.
TEST(FactorialTest, HandlesZeroInput) {
EXPECT_EQ(1, Factorial(0));
}
// Tests factorial of positive numbers.
TEST(FactorialTest, HandlesPositiveInput) {
EXPECT_EQ(1, Factorial(1));
EXPECT_EQ(2, Factorial(2));
EXPECT_EQ(6, Factorial(3));
EXPECT_EQ(40320, Factorial(8));
}
Setting the C++ standard to -std=gnu++0x rather than -std=c++0x, worked for me. You can try the statement:
g++ -std=gnu++0x -DGTEST_OS_CYGWIN=1 -I"E:\source\gtest-1.6.0\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/challenge.d" -MT"src/challenge.d" -o "src/challenge.o" "../src/challenge.cpp"
Setting symbol (-DGTEST_OS_CYGWIN=1) has got nothing to do with this error.
Some functions go beyond the ANSI standard.
These are disabled when you use std=c++11 (or std=c++0x).
Among them are fdopen, fileno and strdup.
There are two possibilities to use them:
Use the GNU dialect (std=gnu++11).
If you want to compile without dialect and make a local exception, you can include stdio.h with the __STRICT_ANSI__ undefined. (see: Error "'fdopen' was not declared" found with g++ 4 that compiled with g++3)
I have tested both on Suse Linux Enterprise 11, MinGW and Cygwin.
Addition: Another (possibly better) way to access non-ANSI symbols would be to add
#define _POSIX_C_SOURCE 200809L
before the first #include in your file. This will give you access to most of the non-standard routines.
Some functions (e.g. realpath(...)) require
#define _BSD_SOURCE
to be inserted on top of your file.