LD_PRELOAD and thread local variable - c++

I have a shared library (libtest.cpp) and a simple program (test.cpp). I want them to share a thread local variable gVar. The shared library is linked through LD_PRELOAD.
Here is my code for the shared library libtest.cpp:
#include<stdio.h>
__thread int gVar;
void print_gVar(){
printf("%d\n", gVar);
}
Below is the code for test.cpp.
#include<stdio.h>
__thread int gVar;
void __attribute__((weak)) print_gVar();
int main(){
gVar = 10;
print_gVar();
return 0;
}
And I use the following script to compile and run them.
g++ -g -shared -fPIC -olibtest.so libtest.cpp
g++ -g -fPIC -o test test.cpp
LD_PRELOAD=./libtest.so ./test
The expected result is 10 because the assignment in test.cpp will affect the gVar in libtest.cpp. However, I only got 0. It seems that the the gVar in libtest.cpp and the gVar in test.cpp are not linked.
I did some additional tests:
If I add __attribute__((weak)) to the declaration of gVar in any of the files, the output is still 0.
If I remove __thread from both files, then the result is 10 (successful).
If I add extern and __attribute__((weak)) to the declaration of gVar in libtest.cpp, there will be segmentation fault.
I guess there must be something wrong with LD_PRELOAD and __thread. But I cannot figure out.
Could anyone tell me how I can make it work? Thank you very much!

This is not possible, since thread-local-storage requires per-thread initialisation.
LD_PRELOAD will load the library even before the standard library is loaded, which messes up TLS initialisation.
Update:
Please read sections 2 and 3 of ELF Handling For Thread-Local Storage

Related

Compiling several source (main and headers) files and linking them in ROOT CINT?

Let me first set the context, it is CERN's ROOT and CINT and ACLiC etc.
Suppose I have a main macro named macro.cpp and two headers h1.cpp (contains the definition of a function) and h1.h containing the declaration of the function defined in h1.cpp similarly I have h2.cpp and h2.h. The main program macro.cpp calls those functions inside h1 and h2. I was successful compiling the source files using:
root [0] .L h1.cpp+
root [1] .L h2.cpp+
root [2] .L macro.cpp+
which generated three .so files macro_cpp.so, h1_cpp.so and h2_cpp.so. I want to know what to do with them ? How do I link them so that I have something like a "macro.out" or something like that (a single executable file of some kind) which I can execute (although I don't know how !) and achieve whatever I wished to achieve with the macro.
Note: If I just load all the files using .L file_name.cpp etc and just execute the main macro using .x macro.cpp then everything works fine and I have results, but this is not what I want ! I want to compile like we do in usual g++ and by the way in every forum everyone keeps advising on compiling using .L file_name.cpp+ or ++ .. I would really like to know the whole story. Because nobody seems to explain beyond .L file_name.cpp+ .. what next ? What to do with the .so etc.
I am a beginner, I will really appreciate a simple and step by step answer and explanation.
Thanks.
Edit-1: I am working with:
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Edit-2: ROOT related information:
ROOT 5.34/36 (v5-34-36#v5-34-36, dic 07 2016, 23:31:51 on linuxx8664gcc)
CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
If you want to compile and link you can use a standard compiler instead of Cint/Aclic.
For example, assuming you are working on a *nix platform, you can use the example files below:
h1.h
int add_one(int a);
h1.cpp
#include "h1.h"
int add_one(int a)
{
return a+1;
}
h2.h
#include <TLorentzVector.h>
TLorentzVector multiply_by_two(const TLorentzVector v);
h2.cpp
#include "h2.h"
TLorentzVector multiply_by_two(const TLorentzVector v)
{
return 2.0*v;
}
macro.cpp
#include "h1.h"
#include "h2.h"
#include <TLorentzVector.h>
#include <iostream>
using std::cout;
using std::endl;
int main()
{
int a = 0;
TLorentzVector v;
v.SetPtEtaPhiM(1.0, 0.0, 0.0, 0.0);
cout<<"calling add_one on "<<a<<": "<<add_one(a)<<endl;
cout<<"calling multiply_by_two on "<<v.Pt()<<": "<<multiply_by_two(v).Pt()<<endl;
return 0;
}
Then you can compile with
g++ -c -g -Wall `root-config --cflags` h1.cpp
g++ -c -g -Wall `root-config --cflags` h2.cpp
g++ -c -g -Wall `root-config --cflags` macro.cpp
and link with
g++ `root-config --glibs` h1.o h2.o macro.o
The executable will be a.out:
$ ./a.out
calling add_one on 0: 1
calling multiply_by_two on 1: 2
You can put these g++ commands in a script or, when you start having several files and directories, you can write your make file (or cmake). For this last step, see for example the tutorial here
http://www-pnp.physics.ox.ac.uk/~brisbane/Teaching/Makefiles/Tutorial_1_Makefiles_and_ROOT.pdf
Note 1: one advantage of using g++ is that you will get clear error messages when something doesn't compile. The error messages from Cint can
be difficult to understand--although this is very much improved in root 6 with Cling.
Note 2: another advantage of using a standard compiler is that you will be able to easily link your main executable against libraries other than root.
This answer is based mostly on the answer by user2148414, but if one follows the answer will notice that there were some issues with the method of linking the source (*.cpp) files. My answer also addresses another important object called a TApplication that will play a crucial role in such applications involving root libraries. The following linking step:
g++ `root-config --glibs` h1.o h2.o macro.o
will likely show a lot of errors complaining about the root objects like TWhatever (in user2148414's answer TLorentzVector will show problems). In the comments to that answer one can find the discussion on including various physics libraries that can solve the problem but without discussing that (and I am not comfortable either :) ) let me write down the command that solves everthing.
This procedure is a one-liner, that is no need to compile individual files, create *.cpp files and *.h files as discussed in that answer then compile and link and create a single executable named "someExecutable" using:
g++ macro.cpp h1.cpp h2.cpp `root-config --libs --cflags` -o someExecutable
or better (and one should do it)
g++ -Wall -Wextra -Werror -pedantic -std=c++14 macro.cpp h1.cpp h2.cpp `root-config --libs --cflags` -o someExecutable
This will solve my original answer but for completeness I would like to add a few more things.
TApplication
My original motivation was to create an application that talks to "ROOT" but I didn't want to work with the ROOT shell, CINT, ACLiC etc and wanted to work entirely with g++. user2148414's and my answer will solve the part of creating an application but the application will not serve any purpose, it will run, create histograms draw them and do all the stuff but all the canvases will close in the end when the code reaches "return 0;". To keep the canvases open we will need "TApplication". So the consider the main of user2148414's answer, I am going include just two more lines and include two arguments to the main:
macro.cpp
#include "h1.h"
#include "h2.h"
#include <TLorentzVector.h>
#include <iostream>
using std::cout;
using std::endl;
int main(int argc, char* argv[]) //introduced arguments to main
{
// here I introduce TApplication
TApplication* SomeApp = new TApplication("SomeApp",&argc, argv);
int a = 0;
TLorentzVector v;
v.SetPtEtaPhiM(1.0, 0.0, 0.0, 0.0);
cout<<"calling add_one on "<<a<<": "<<add_one(a)<<endl;
cout<<"calling multiply_by_two on "<<v.Pt()<<": "<<multiply_by_two(v).Pt()<<endl;
//and just before returning 0
SomeApp->Run();
return 0;
}

Memory still reachable bug fixed, but why?

I'm experimenting with shared libraries to build a modularized program.
There are two cpp files to compile:
Shared library, compile with
g++ -fPIC -shared module.cpp -o module.so
//module.cpp
#include <iostream>
File using the shared library, compile with
g++ src/main.cpp -ldl -o binary
or
g++ -DFIX src/main.cpp -ldl -o binary
//main.cpp
#include <dlfcn.h>
#ifdef FIX
# include <iostream>
#endif
int main()
{
void* h = dlopen("./module.so", RTLD_LAZY);
if ( h )
{
dlclose(h);
}
}
With FIX undefined, valgrind reports lot's of still reachable memory (5,373bytes), with FIX defined, no memory is leaked.
What's the problem with using iostream in shared libraries?
This problem occurs with g++-4.6, g++-4.7 and g++-4.8. g++-4.4 does not show this behaviour. I don't have other compilers to test with, sadly (and I don't want to switch to g++-4.4 because of this).
Update:
Compiling the shared library file with the additional flags -static-libstdc++ -static-libgcc reduces the number of leaked blocks, but not completely. -static-libgcc alone has no effect, -static-libstdc++ has some effect, but not as much as both.
1. Why or how does this code snippet "fix" the issue?
I'm not sure why without digging into the libstdc++ code, but I assume that the memory allocated by the iostreams library, which is kept allocated for the duration of the whole program, is reported as a problem by valgrind when it is allocated in a shared library, but not when allocated in the main program.
2. What equivalent, independent (from the standard library) code snippet provides the same bug fix?
Firstly, I don't know why you want something "independent from the standard library" when the still reachable memory is probably being allocated by the standard library. The fix is either don't use the standard library at all, anywhere, or use it differently.
Secondly, that "fix" is undefined behaviour, because you violate the One Definition Rule by redefining std::ios_base differently to the proper definition in the std lib.
The correct way to get the same behaviour is to #include <iostream> in your main.cpp file, including <iostream> defines a static std::ios_base::Init object. Alternatively, just #include <ios> and then define the static variable (but don't redefine the std::ios_base type) but that's basically what <iostream> does, so you might as well use that.

Link dynamic shared library in Linux - Undefined reference to function

I know there are many questions related to shared libraries on Linux but maybe because I'm tired of having a hard day trying to create a simple dynamic library on Linux (on Windows it would have taken less than 10 minutes) I can't find what happens in this case.
So, I am trying to create a library to be linked at build-time and used at run-time (not a static library, not a library to be embedded into the executable, in other words). For now it contains a simple function. These are my files:
1.
// gugulibrary.cpp
// This is where my function is doing its job
#include "gugulibrary.h"
namespace GuGu {
void SayHello() {
puts("Hello!");
}
}
2.
// gugulibrary.h
// This is where I declare my shared functions
#include <stdio.h>
namespace Gugu {
void SayHello();
}
3.
// guguapp.cpp
// This is the executable using the library
#include "gugulibrary.h"
int main() {
GuGu::SayHello();
return 0;
}
This is how I try to build my project (and I think this is what is wrong):
gcc -Wall -s -O2 -fPIC -c gugulibrary.cpp -o gugulibrary.o
ld -shared -o bin/libGugu.so gugulibrary.o
gcc -Wall -s -O2 guguapp.cpp -o bin/GuGu -ldl
export LD_LIBRARY_PATH=bin
This is saved as a .sh file which I click and execute in a terminal. The error I get when trying to link the library is this:
/tmp/ccG05CQD.o: In function `main':
guguapp.cpp:(.text.startup+0x7): undefined reference to `SayHello'
collect2: ld returned 1 exit status
And this is where I am lost. I want the library to sit in the same folder as the executable for now and maybe I need some symbols/definitions file or something, which I don't know how to create.
Thanks for your help!
In your C++ file, GuGu::SayHello is declared as a C++ symbol. In your header, you are wrapping it in an extern "C" block. This is actually undefined, as you aren't allowed to use C++ syntax (namespace) in that context. But my guess is that what the compiler is doing is ignoring the namespace and generating a C symbol name of "SayHello". Obviously such a function was never defined by your library. Take out the extern "C" bits, because your API as defined cannot be used from C anyway.
You are inconsistent with your GuGu, there are also Gugu's running around, this needs to be made consistent, then it works (At least on my computer are some Gugu's now)

Solaris shared libraries and global variables

I have an issue with global variables in shared library on Solaris.
Consider following sample:
class Foo
{
public:
Foo() { Init(); }
private:
void Init() { // do something }
};
I have some code in shared library:
Foo g_Foo;
I've noticed that Foo constructor is never called on Solaris while the same code works Linux.
I'm using gcc 3.4.3 and Sun linker.
Are you creating the shared object with the -G flag? e.g.
CC -G -o mylib.so myfile.cpp
If you don't specify -G, then the compiler may not initialise global variables correctly. See compiler documentation here.
Note, the docs also say you can't use ld, but need to use CC to do the linking.

Compiling C++ using -pthreads for Openwrt Linux-Get segmentation fault

I´m pretty new to programming in C++ and I´m using pthreads. I´m cross compiling my code for OpenWRT but for some reason I get segmentation fault when I run the program on my board but it runs fine on my PC. I suspect that the error occurs in the linking stage of the compilation because I tried a small C program and that worked fine. Also if I change the name of the file to .cpp and compile it with g++ it also works.
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
void *run(void *dummyPtr) {
printf("I am a thread...\n");
return NULL;
}
int main(int argc, char **argv) {
printf("Main start...\n");
pthread_t connector;
pthread_create(&connector, NULL, run, NULL);
printf("Main end...\n");
return 0;
}
The output from the eclipse compiler:
**** Build of configuration Release for project ThreadTest ****
make all
Building file: ../src/ThreadTest.cpp
Invoking: GCC C++ Compiler
mipsel-linux-g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/ThreadTest.d" -MT"src/ThreadTest.d" -o"src/ThreadTest.o" "../src/ThreadTest.cpp" -lpthread
mipsel-linux-g++: -lpthread: linker input file unused because linking not done
Finished building: ../src/ThreadTest.cpp
Building target: ThreadTest
Invoking: GCC C++ Linker
mipsel-linux-g++ -o"ThreadTest" ./src/ThreadTest.o -lpthread -static
Finished building target: ThreadTest
Edit: Removed the old code and put in a new simpler example. This code runs if I compile it as a C program but no if I compile it as a c++ program. I´m runnig the 2.6.26.3 kernel on the board.
This could easily be due to a low memory condition. You should try to enable some form of page file and free up any other memory.
Also, why -static? if your using a dynamic -lpthread, wouldn't linking the shared library be preferable?
Also, it could be due to your C++ lib being mis-matched, make sure your uclibc++ is the correct version, you may also want to install ldd if you have not already. Depends on your firmware.
It's not sufficient to simple link against pthread with -lpthread. You need gcc -pthread (as an option its own right) or gcc -D_REENTRANT -lpthread (define a symbol named _REENTRANT). I don't know if this necessary affects anything.
I don't know if you found an answer yet or if this was the problem, but there is a race condition in the code you showed. It is possible that main will return and your program will try to exit before your "run" thread has finished running. You can never assume that it will run in any particular order or with any particular timing. You should add a call to pthread_join(connector, NULL); before returning from main.
Before returning from the main and thus exiting the program, you should be doing a
pthread_join(connector, NULL);
which avoids exiting your application before the thread has terminated.
A correct declaration of main() is
int main(int argc, char **argv)
Edited to correct this answer:
This is because your compile -c line for your .c include -lpthread: linker input file unused
I found this answer about compiling c++ programs on openwrt:
http://manoftoday.wordpress.com/2007/10/11/writing-and-compiling-a-simple-program-for-openwrt/
I think you'll also want to read this to get gdb working:
http://forum.openwrt.org/viewtopic.php?pid=29712