I have to extend a C program which controls a single drone (parrot AR Drone). The goal is to control a squadron of drones, but the API uses a huge amount of global variables (drone IP, ports, drone status...). How can I instanciate several times the library, without having "collision" between instances?
The only solution I've found is to modify the API (which is open source) to call fork() somewhere in the main() function, and I'd like to avoid this...
I would recommend just wrapping the library in a service process. Then you can run one instance of the service process for each drone. Otherwise, fix the library to take a context parameter.
dlmopen can load one library multiple times. But it's limited to 15 times.
You can also create multiple copies of your library and load each of them.
Use macros to replace all of the global variables like this:
#define global1 ctx->global1
#define global2 ctx->global2
...
Then add a struct context *ctx argument to every function.
Alternatively, add _Thread_local (or __thread with old versions of gcc) to each global variable, then run each "instance" in its own thread so it naturally has its own copies of the globals available to it.
Related
There's an app that uses TLS callbacks to remap its memory using (NtCreateSection/NtUnmapViewOfSection/NtMapViewOfSection) using the SEC_NO_CHANGE flag.
Is there any way to hook NtCreateSection before the target app use it on its TLS callback?
You could use API Monitor to check if it is really that function call and if I understand you correctly you want to modify its invocation. API Monitor allows you to modify the parameters on the fly. If just "patching" the value when the application accesses the api is enough you could than use x64dbg to craft a persistent binary patch for your application. But this requires you to at least know or get familiar with basic x64/x86 assembler.
I have no idea what you're trying to achieve exactly but if you're trying to execute setup code before the main() function is called (to setup hooks), you could use the constructor on a static object. You would basically construct an object before your main program starts.
// In a .cpp file (do not put in a header as that would create multiple static objects!)
class StaticIntitializer {
StaticIntitializer(){
std::cout << "This will run before your main function...\n";
/* This is where you would setup all your hooks */
}
};
static StaticInitializer staticInitializer;
Beware though, as any object constructed this way might get constructed in any order depending on compilers, files order, etc. Also, some things might not be initialized yet and you might not be able to achieve what you want to setup.
That might be a good starting point, but as I said, I'm not sure exactly what you're trying to achieve here, so good luck and I hope it helps a little.
I have a pretty large application which holds most of the program data in a large container object called system.
So I access things all the time, e.g. printf("%s\n",system.constants.jobname);, and changing the name of system is undesirable.
I learned later that the function system exists as a native C function for running terminal commands, e.g. system("rm *.txt");
My problem is that I get compilation errors trying to use system as a function because it's already defined as an object.
Is there any way one can call a native C function explicitly ignoring programmatically defined variables? Or give the native system function an alias? (I'm using C++ so using it would be fine)
If you're using C++, system is in the global namespace. Assuming you've put your stuff in a proper namespace (you have, right?) you can refer to it as ::system.
Assuming using shared libraries is an acceptable solution, you can do this.
Create another C file which will not use your system container. Now write a function my_system that is a wrapper to system.
By wrapper I mean, it takes the same argument and calls system and returns what system returns.
Don't forget to export my_system
Now compile this as a dll (or .so on *NIX).
In your main project, load the dll and get a handle. Now query for address of my_system on the handle and make the call using function pointer.
For the C++ library I am currently developing I have seen the advantages of a plug-in system based on shared libraries. A feature will become available to the user of the library just if one of the shared libraries that are in a directory scanned at initialization time is offering that.
Using dlopen, the shared libraries will be searched for two symbols: one function that returns the string that names the feature they implement, and a create function that instantiates the class and returns a pointer to the basse class. Something like this:
In Library A
#include "Instance.hpp"
extern "C" const char* type() {
return "InstanceA";
}
//... class InstanceA definition, inherits from Instance
extern "C" Instance* create() {
return new InstanceA();
}
The Core library will scan the plug-ins directory and keep a map string->pointerToCreateFunction in order to create new instances.
This is really handy, and a pretty standard thing to do. If the user code tries to instantiate an InstanceX but no shared library implement that type, an error will be given, everything will work perfectly.
But this framework will be used also for iOs development, and the App Store doesn't allow loading 3rd party shared objects. I would like to keep this modular plug-in structure even when loading a self contained version of the library that links statically the plugins. Note that at project management level this would be as easy as defining a variable in CMake that creates static versions of the plugins and links them statically. This would also exclude the dynamic loading part of the code.
What I am missing is how to invert the mechanism: while for shared objects the core library will leverage on the file system to learn about the possible type of instances that can be used, I don't know how to "register" them without changing big part of the code, and without going in the static initialization fiasco. Looks like the only way to have that is subsituting the code that scans the types and the create function by including all the possible headers and having a big switch like
Instance* theInstance;
if (instanceRequired == "instanceA")
theInstance = new InstanceA();
etc etc...
Do you have any thought on a way to avoid including all the headers and having to change the code in Core each time a new instance is added?
I do such things through those pesky static objects that call register in ctor.
The ordering problem is dodged by making the map itself a local static, so getting constructed on the first client call, wherever it comes from. (Threading and similar issues are dodged by restricting thread launch to until-main time, and by that time all important things are forced.)
class RegMap; // the registry
RegMap& GetRegistry(); // the singleton access function; you can make a separate const/nonconst version or provide another wrapper for registering
// implementation in core.cpp:
RegMap& GetRegistry()
{
static RegMap m;
return m;
}
//in client ctor:
GetRegistry().Register( key, func);
I have some global variables (classes) that as I understand have created before main() call. I need some technique to add data to a List of something either global or as member of that class from any part of my code and it have to be filled before Linker. To use it inside globally created classes. Is it possible? I did not find any similar solution or even question, so any help will be appreciated.
Detailed example:
I've have singleton class which has a variable that was filled in the constructor. All other classes use data from the class at run time someone early someone later. Singleton class is created at the begin of main function. I am using singleton in different projects, data that it has mostly universal for all projects and modules except special flag which should show requirement for this module. If singleton throw exception program exits and we know it at the first steps of execution because singleton creates at first lines of the main. So singleton has a lot of universal data for all projects but I need to add flags to point for singleton which data is required for each module. I have created template for main so for each project I have the same main with just simple define PROJECT_NAME later I add .cpp to the project and they have to register which data is required and which not.
This explanation not looks like perfect, if it is not understandable don't hesitate to say it I will organize it more deliberately.
Edited:
I'm still looking for solution in the Internet, and found constexpr it looks like what I need, but at this moment it is not supported by all compilers, is there some workaround ?
First step is to not use global variables, but instead use static variables within a global function. The first time the function is called the variable will be initialized and then have the function return a reference to the varaible.
my_class& instnace() {
static my_class i;
return i;
}
A list example:
std::list<my_class>& global_list() {
static std::list<my_class> m; return m;
}
static int x = []()->int{ global_list().push_back(my_class); return 0;}();
If you want to accomplish what you want from different modules , one of the way is to have things done is some sort of callback function when your dll is loaded.
One windows it is DLLMain.
An optional entry point into a dynamic-link library (DLL). When the
system starts or terminates a process or thread, it calls the
entry-point function for each loaded DLL using the first thread of the
process. The system also calls the entry-point function for a DLL when
it is loaded or unloaded using the LoadLibrary and FreeLibrary
functions.
On other platforms with gcc you can get by the [attribute constructor]
constructor The constructor attribute causes the function to be called
automatically before execution enters main (). Similarly, the
destructor attribute causes the function to be called automatically
after main () has completed or exit () has been called. Functions with
these attributes are useful for initializing data that will be used
implicitly during the execution of the program. These attributes are
not currently implemented for Objective-C.
Warning
It is very easy to shoot yourself in the foot with this method. At least on windows that are lot of things you cannot do in the dll entry point. Please read your compiler/os documentation to see what the limitations are.
We have an application written in C/C++ which is broken into a single EXE and multiple DLLs. Each of these DLLs makes use of the same static library (utilities.lib).
Any global variable in the utility static library will actually have multiple instances at runtime within the application. There will be one copy of the global variable per module (ie DLL or EXE) that utilities.lib has been linked into.
(This is all known and good, but it's worth going over some background on how static libraries behave in the context of DLLs.)
Now my question.. We want to change utilities.lib so that it becomes a DLL. It is becoming very large and complex, and we wish to distribute it in DLL form instead of .lib form. The problem is that for this one application we wish to preserve the current behaviour that each application DLL has it's own copy of the global variables within the utilities library. How would you go about doing this? Actually we don't need this for all the global variables, only some; but it wouldn't matter if we got it for all.
Our thoughts:
There aren't many global variables within the library that we care about, we could wrap each of them with an accessor that does some funky trick of trying to figure out which DLL is calling it. Presumably we can walk up the call stack and fish out the HMODULE for each function until we find one that isn't utilities.dll. Then we could return a different version depending on the calling DLL.
We could mandate that callers set a particular global variable (maybe also thread local) prior to calling any function in utilities.dll. The utilities DLL could then use this global variable value to determine the calling context.
We could find some way of loading utilities.dll multiple times at runtime. Perhaps we'd need to make multiple renamed copies at build time, so that each application DLL can have it's own copy of the utilities DLL. This negates some of the advantages of using a DLL in the first place, but there are other applications for which this "static library" style behaviour isn't needed and which would still benefit from utilities.lib becoming utilities.dll.
You are probably best off simply having utilities.dll export additional functions to allocate and deallocate a structure that contains the variables, and then have each of your other worker DLLs call those functions at runtime when needed, such as in the DLL_ATTACH_PROCESS and DLL_DETACH_PROCESS stages of DllEntryPoint(). That way, each DLL gets its own local copy of the variables, and can pass the structure back to utilities.dll functions as an additional parameter.
The alternative is to simply declare the individual variables locally inside each worker DLL directly, and then pass them into utilities.dll as input/output parameters when needed.
Either way, do not have utilities.dll try to figure out context information on its own. It won't work very well.
If I were doing this, I'd factor out all stateful global variables - I would export a COM object or a simple C++ class that contains all the necessary state, and each DLL export would become a method on your class.
Answers to your specific questions:
You can't reliably do a stack trace like that - due to optimizations like tail call optimization or FPO you cannot determine who called you in all cases. You'll find that your program will work in debug, work mostly in release but crash occasionally.
I think you'll find this difficult to manage, and it also puts a demand that your library can't be reentrant with other modules in your process - for instance, if you support callbacks or events into other modules.
This is possible, but you've completely negated the point of using DLL's. Rather than renaming, you could copy into distinct directories and load via full path.