I have a problem while running an executable file with dlopen function used to open shared and sanitized library with a one simple function.
I use precompiled Clang 3.9.0 for Ubuntu 14.04.
My question is: Is it possible to run it properly, so I can look for undefined behavior errors in the library while running an executable ? If the answers is yes, then how ?
I have two files:
//simpledll.cpp
#include <cstdio>
int hehe(int argc) {
int k = 0x7fffffff;
k += argc;
return 0;
}
//dlopen.cpp
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
int main() {
void* handle;
handle = dlopen("simpledll.so", RTLD_LAZY);
if(!handle) {
fprintf(stderr, "%s\n", dlerror());
}
int (*function)(int) = reinterpret_cast<int (*)(int)> (dlsym(handle, "_Z4hehei"));
if (function == nullptr)
fprintf(stderr, "Nope\n");
else
function(1000); // this yields signed integer overflow
return 0;
}
I have tried to get it to work in two steps (both have failed)
Step I
Compile the executable with:
clang++ dlopen.cpp -ldl --std=c++11 -o dlopen
Compile the library with:
clang++ -fsanitize=undefined -shared -o simpledll.so -fPIC simpledll.cpp
Result:
./dlopen: symbol lookup error: simpledll.so: undefined symbol: __ubsan_handle_add_overflow
Step II (idea from this forum)
Compile the executable as in Step I,
Compile the library with:
clang++ -fsanitize=undefined -shared -Wl,--whole-archive -L/usr/local/lib/clang/3.9.0/lib/linux/ -lclang_rt.ubsan_standalone_cxx-x86_64 -Wl,--no-whole-archive -lclang_rt.ubsan_standalone-x86_64 -Wl,--no-whole-archive -o simpledll.so -fPIC simpledll.cpp
Result:
==11478==Sanitizer CHECK failed: /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/ubsan/ubsan_init.cc:61 ((UBSAN_MODE_UNKNOWN)) != ((ubsan_mode)) (0, 0)
Note that in Step II, if we substitute the function in the shared library with the one that has no undefined behavior code, the program runs without a CHECK failed error. This indicates that UBSAN has found an undefined behavior code, however it was unable to report it properly.
Regards,
Jaszczur
Related
I'm using c++ builder 10.2 with the clang compiler on Windows 10 pro. Can anyone tell me why this doesn't compile?
// crt_tzset.cpp
// This program uses _tzset to set the global variables
// named _daylight, _timezone, and _tzname. Since TZ is
// not being explicitly set, it uses the system time.
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
int main( void )
{
_tzset();
int daylight;
_get_daylight( &daylight );
printf( "_daylight = %d\n", daylight );
long timezone;
_get_timezone( &timezone );
printf( "_timezone = %ld\n", timezone );
size_t s;
char tzname[100];
_get_tzname( &s, tzname, sizeof(tzname), 0 );
printf( "_tzname[0] = %s\n", tzname );
exit( 0 );
}
I get 3 'Unresolved external' errors relating to _get_daylight, _get_timezone and _get_tzname.
Since I don't have "c++builder", I tried this with MinGW.
With a straightforward compile and link command like this:
gcc -Wall -Werror -pedantic -O2 tz.c -o tz
I got the same errors:
C:\Users\###\AppData\Local\Temp\ccI8j8Mj.o:tz.c:(.text.startup+0x1f): undefined reference to `__imp__get_daylight'
C:\Users\###\AppData\Local\Temp\ccI8j8Mj.o:tz.c:(.text.startup+0x3a): undefined reference to `__imp__get_timezone'
C:\Users\###\AppData\Local\Temp\ccI8j8Mj.o:tz.c:(.text.startup+0x61): undefined reference to `__imp__get_tzname'
collect2.exe: error: ld returned 1 exit status
A single grep revealed the library libucrtbase.a (among others) to contain the symbol _get_daylight. Adding this library to the command:
gcc -Wall -Werror -pedantic -O2 tz.c -lucrtbase -o tz
This produced a runnable program.
The other libraries are all libmsvcr*.a in different versions, I tried just one of them. This was successful, too.
Edit:
With a not-so-current "clang" I didn't even need to add the library.
clang -Wall -Werror -pedantic -O3 tz.c -o tz-clang.exe
This compiled and linked without any error and runs perfectly.
(clang version 7.0.1 (tags/RELEASE_701/final), Target: x86_64-pc-windows-msvc)
I have one C program which I want to load into my running C program. Following are the snippet
File : a.c
#include <stdio.h>
void abc() {
printf("This is abc\n");
}
File : mainFile.cpp
#include<stdio.h>
#include <dlfcn.h>
int main(int argc, char **argv) {
void *lib = dlopen("./a.so", RTLD_LAZY);
if (!lib) {
printf("dlopen failed: %s\n", dlerror());
return 1;
}
void (*f)() = dlsym(lib, "abc");
if (f) {
f();
} else {
printf("dlsym for f1 failed: %s\n", dlerror());
}
dlclose(lib);
return 0;
}
I am compiling with the following commands
gcc -fpic -g -shared -ldl -o a.so a.c
g++ -w mainFile.cpp -o mainFile
Output:
/tmp/cc9fYZaf.o: In function `main':
mainFile.cpp:(.text+0x1a): undefined reference to `dlopen'
collect2: error: ld returned 1 exit status
I am compiling in Ubuntu 16.04 with gcc version gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
Please help
Note: I have followed the following references but none helped.
Can you dynamically compile and link/load C code into a C program?
undefined reference to `dlopen' since ubuntu upgrade
undefined reference to `dlopen'
The second line — the one which links the executable — needs the -ldl, not the first:
g++ -w mainFile.cpp -ldl -o mainFile
I am currently using Boost 1.54.0. I am following the code from this example.
example_44_01.cpp
#include <boost/thread.hpp>
#include <boost/chrono.hpp>
#include <iostream>
void wait(int seconds)
{
boost::this_thread::sleep_for(boost::chrono::seconds{seconds});
}
void thread()
{
for (int i = 0; i < 5; ++i)
{
wait(1);
std::cout << i << std::endl;
}
}
int main(int argc, char** argv)
{
boost::thread t{thread};
t.join();
return 0;
}
So, it looks like all I need is the -lboost_thread, and -lboost_chrono libraries to link to at compile time. I also added the -lboost_system.
Here are my execution scripts.
g++-7 -Wall -std=c++1z -g -c example_44_01.cpp -o example_44_01.o
g++-7 -Wall -std=c++1z -g example_44_01.o -o example_44_01 -lboost_system -lboost_thread -lboost_chrono &>result.txt
What's going on here? This is the result.txt file:
example_44_01.o: In function `boost::this_thread::sleep_for(boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > const&)':
/usr/local/include/boost/thread/pthread/thread_data.hpp:243: undefined reference to `boost::this_thread::hidden::sleep_for(timespec const&)'
collect2: error: ld returned 1 exit status
I've compiled and linked other programs with the same libraries without error. So is the error in the code? This seems doubtful as the code is straight from the documentation. Any insight is appreciated.
I had this issue once because I was indeliberately using different versions of Boost (I had first installed Boost from commandline, then a few months later on, manually from zip).
Try adding the path to your Boost libraries to the compiler. For instance, if your libraries are stored at /usr/local/lib, try:
g++-7 -Wall -std=c++1z -g example_44_01.o -o example_44_01 -L/usr/local/lib -lboost_system -lboost_thread -lboost_chrono &>result.txt
I've been trying to compile with std::atomic, and I'm getting unresolved references to __atomic_load, __atomic_store, and __atomic_store_16.
I know in a later version of gcc (4.8+?) you include -latomic, but I'm compiling with gcc 4.7.3; I've tried adding -latomic_ops and -latomic_ops_gpl, but neither seem to do much.
I am installing gcc 4.8.1 now, but I do have a release platform that'll really need to be compiled for 4.7.3.
Many thanks.
Edit:
Ok, here's some code that results in the problem I have:
atomics.cpp
#include <atomic>
#include <stdint.h>
struct dataStruct {
int a;
uint16_t b;
float c;
dataStruct(int ai, uint16_t bi, float ci) noexcept : a(ai), b(bi), c(ci) {
}
dataStruct() noexcept : dataStruct(0,0,0) {
}
};
int main() {
std::atomic<dataStruct> atomicValue;
atomicValue = dataStruct(10, 0, 0);
return atomicValue.load().b;
}
With "g++-4.8.1 *.cpp -std=c++0x -latomic", this compiles fine.
With "g++-4.7.3 *.cpp -std=c++0x -pthread -lpthread -latomic_ops", it fails with the following:
/tmp/ccQp8MJ2.o: In function `std::atomic<dataStruct>::load(std::memory_order) const':
atomics.cpp:(.text._ZNKSt6atomicI10dataStructE4loadESt12memory_order[_ZNKSt6atomicI10dataStructE4loadESt12memory_order]+0x2f): undefined reference to `__atomic_load'
/tmp/ccQp8MJ2.o: In function `std::atomic<dataStruct>::store(dataStruct, std::memory_order)':
atomics.cpp:(.text._ZNSt6atomicI10dataStructE5storeES0_St12memory_order[_ZNSt6atomicI10dataStructE5storeES0_St12memory_order]+0x35): undefined reference to `__atomic_store'
collect2: error: ld returned 1 exit status
Ok, finally found the answer at: https://gcc.gnu.org/wiki/Atomic/GCCMM
Turns out, 4.7 did not in fact have 'official' atomics support (just the header files). If you want to use atomics in 4.7 compilers, you must download the source code linked on that page and build it yourself
gcc -c -o libatomic.o libatomic.c
ar rcs libatomic.a libatomic.o
Then, you can build it using
g++-4.7.3 -std=c++0x atomics.cpp -latomic -L./
I'm trying to write a program to use a static library of a C++ code into another C++ code. The first C++ code is hello.cpp:
#include <iostream>
#include <string.h>
using namespace std;
extern "C" void say_hello(const char* name) {
cout << "Hello " << name << "!\n";
}
int main(){
return 0;
}
The I made a static library from this code, hello.a, using this command:
g++ -o hello.a -static -fPIC hello.cpp -ldl
Here's the second C++ code to use the library, say_hello.cpp:
#include <iostream>
#include <string>
#include <dlfcn.h>
using namespace std;
int main(){
void* handle = dlopen("./hello.a", RTLD_LAZY);
cout<<handle<<"\n";
if (!handle) {
cerr<<"Cannot open library: "<<dlerror()<<'\n';
return 1;
}
typedef void (*hello_t)();
dlerror(); // reset errors
hello_t say_hello = (hello_t) dlsym(handle, "say_hello");
const char *dlsym_error = dlerror();
if (dlsym_error) {
cerr<<"Cannot load symbol 'say_hello': "<<dlsym_error<<'\n';
dlclose(handle);
return 1;
}
say_hello("World");
dlclose(handle);
return 0;
}
Then I compiled say_hello.cpp using:
g++ -W -ldl say_hello.cpp -o say_hello
and ran ./say_hello in the command line. I expected to get Hello World! as output, but I got this instead:
0x8ea4020
Hello ▒▒▒▒!
What is the problem? Is there any trick to make compatibility for method's argument like what we use in ctypes or what?
If it helps I use a lenny.
EDIT 1:
I have changed the code and used a dynamic library, 'hello.so', which I've created using this command:
g++ -o hello.so -shared -fPIC hello.cpp -ldl
The 6th line of the code changed to:
void* handle = dlopen("./hello.so", RTLD_LAZY);
When I tried to compile say_hello.cpp, I got this error:
say_hello.cpp: In function ‘int main()’:
say_hello.cpp:21: error: too many arguments to function
I also tried to compile it using this line:
g++ -Wall -rdynamic say_hello.cpp -ldl -o say_hello
But same error raised. So I removed the argument "World" and the it has been compiled with no error; but when I run the executable, I get the same output like I have mentioned before.
EDIT 2:
Based on #Basile Starynkevitch 's suggestions, I changed my say_hello.cpp code to this:
#include <iostream>
#include <string>
#include <dlfcn.h>
using namespace std;
int main(){
void* handle = dlopen("./hello.so", RTLD_LAZY);
cout<<handle<<"\n";
if (!handle) {
cerr<<"Cannot open library: "<<dlerror()<<'\n';
return 1;
}
typedef void hello_sig(const char *);
void* hello_ad = dlsym(handle, "say_hello");
if (!hello_ad){
cerr<<"dlsym failed:"<<dlerror()<<endl;
return 1;
}
hello_sig* fun = reinterpret_cast<hello_sig*>(hello_ad);
fun("from main");
fun = NULL;
hello_ad = NULL;
dlclose(handle);
return 0;
}
Before that, I used below line to make a .so file:
g++ -Wall -fPIC -g -shared hello.cpp -o hello.so
Then I compiled say_hello.cpp wth this command:
g++ -Wall -rdynamic -g say_hello.cc -ldl -o say_hello
And then ran it using ./say_hello. Now everything is going right. Thanks to #Basile Starynkevitch for being patient about my problem.
Functions never have null addresses, so dlsym on a function name (or actually on any name defined in C++ or C) cannot be NULL without failing:
hello_t say_hello = (hello_t) dlsym(handle, "say_hello");
if (!say_hello) {
cerr<<"Cannot load symbol 'say_hello': "<<dlerror()<<endl;
exit(EXIT_FAILURE);
};
And dlopen(3) is documented to dynamically load only dynamic libraries (not static ones!). This implies shared objects (*.so) in ELF format. Read Drepper's paper How To Use Shared Libraries
I believe you might have found a bug in dlopen (see also its POSIX dlopen specification); it should fail for a static library hello.a; it is always used on position independent shared libraries (like hello.so).
You should dlopen only position independent code shared objects compiled with
g++ -Wall -O -shared -fPIC hello.cpp -o hello.so
or if you have several C++ source files:
g++ -Wall -O -fPIC src1.cc -c -o src1.pic.o
g++ -Wall -O -fPIC src2.cc -c -o src2.pic.o
g++ -shared src1.pic.o src2.pic.o -o yourdynlib.so
you could remove the -O optimization flag or add -g for debugging or replace it with -O2 if you want.
and this works extremely well: my MELT project (a domain specific language to extend GCC) is using this a lot (generating C++ code, forking a compilation like above on the fly, then dlopen-ing the resulting shared object). And my manydl.c example demonstrates that you can dlopen a big lot of (different) shared objects on Linux (typically millions, and hundred of thousands at least). Actually the limitation is the address space.
BTW, you should not dlopen something having a main function, since main is by definition defined in the main program calling (perhaps indirectly) dlopen.
Also, order of arguments to g++ matters a lot; you should compile the main program with
g++ -Wall -rdynamic say_hello.cpp -ldl -o say_hello
The -rdynamic flag is required to let the loaded plugin (hello.so) call functions from inside your say_hello program.
For debugging purposes always pass -Wall -g to g++ above.
BTW, you could in principle dlopen a shared object which don't have PIC (i.e. was not compiled with -fPIC); but it is much better to dlopen some PIC shared object.
Read also the Program Library HowTo and the C++ dlopen mini-howto (because of name mangling).
example
File helloshared.cc (my tiny plugin source code in C++) is
#include <iostream>
#include <string.h>
using namespace std;
extern "C" void say_hello(const char* name) {
cout << __FILE__ << ":" << __LINE__ << " hello "
<< name << "!" << endl;
}
and I am compiling it with:
g++ -Wall -fPIC -g -shared helloshared.cc -o hello.so
The main program is in file mainhello.cc :
#include <iostream>
#include <string>
#include <dlfcn.h>
#include <stdlib.h>
using namespace std;
int main() {
cout << __FILE__ << ":" << __LINE__ << " starting." << endl;
void* handle = dlopen("./hello.so", RTLD_LAZY);
if (!handle) {
cerr << "dlopen failed:" << dlerror() << endl;
exit(EXIT_FAILURE);
};
// signature of loaded function
typedef void hello_sig_t(const char*);
void* hello_ad = dlsym(handle,"say_hello");
if (!hello_ad) {
cerr << "dlsym failed:" << dlerror() << endl;
exit(EXIT_FAILURE);
}
hello_sig_t* fun = reinterpret_cast<hello_sig_t*>(hello_ad);
fun("from main");
fun = NULL; hello_ad = NULL;
dlclose(handle);
cout << __FILE__ << ":" << __LINE__ << " ended." << endl;
return 0;
}
which I compile with
g++ -Wall -rdynamic -g mainhello.cc -ldl -o mainhello
Then I am running ./mainhello with the expected output:
mainhello.cc:7 starting.
helloshared.cc:5 hello from main!
mainhello.cc:24 ended.
Please notice that the signature hello_sig_t in mainhello.cc should be compatible (homomorphic, i.e. the same as) with the function say_hello of the helloshared.cc plugin, otherwise it is undefined behavior (and you probably would have a SIGSEGV crash).