I'm trying to add some custom code to our internal libc related to atexit handling.
In our libc we define this because we link to custom CRT files and don't use GCC's which defines this.
void *__dso_handle __attribute__((__visibility__("hidden"),__weak__)) = &__dso_handle;
GCC also adds this to binaries when linking them.
In the libc is the function atexit which just calls
int atexit(void (*func)(void))
{
return __cxa_atexit((void (*)(void*))func, NULL, __dso_handle);
}
The issue I'm facing is that the _dso_handle value used is the local one from libc when I'd like to make it dynamically fetch the one from the module that calls atexit() at runtime so that the proper dso is registered with the atexit function.
I checked attributes and I found nothing that could help there.
Note that unlike glibc, atexit is kept in the dynamic version of libc to preserve backwards compatibility with older binaries.
The issue I'm facing is that the _dso_handle value used is the local one from libc when I'd like to make it dynamically fetch the one from the module that calls atexit() at runtime
Your module can call __cxa_atexit instead, and pass in whatever dso_handle you desire.
Related
I have a D module which I hope contains public and private parts. I have tried using the keywords private and static before function definitions. I have a function that I wish to make externally-callable / public and ideally I would like it to be inlined at the call-site. This function calls other module-internal functions that are intended to be private, i.e. not externally callable. Calls to these are successfully inlined within the module and a lot of the cruft is disposed of by CTFE plus known-constant propagation. However the GDC compiler also generates copies of these internal routines, even though they have been inlined where needed and they are not supposed to be externally callable. I'm compiling with -O3 -frelease. What should I be doing - should I expect this even if I use static and/or private?
I have also taken a brief look at this thread concerning GCC hoping for insight.
As I mentioned earlier, I've tried both using private and static on these internal functions, but I can't seem to suppress the code generation. I could understand this if a debugger needed to have copies of these routines to set breakpoints in. I need to stress that this could perhaps be sorted out somehow at link-time, for all I know. I haven't tried linking the program, I'm just looking at the generated code in the Matt Godbolt D Compiler Explorer using GDC. Everything can be made into templates with a zero-length list of template parameters (e.g. auto my_fn()( in arg_t x ) ), tried that, it doesn't help but does no harm.
A couple of other things to try: I could try and make a static class with private parts, as a way of implementing a package, Ada-style. (Needs to be single-instance strictly.) I've never done any C++, only massive amounts of asm and C professionally. So that would be a learning curve.
The only other thing I can think of is to use nested function definitions, Pascal/Ada-style, move the internal routines to be inside the body of their callers. But that has a whole lot of disadvantages.
Rough example
module junk;
auto my_public_fn() { return my_private_fn(); }
private
static // 'static' and/or 'private', tried both
auto my_private_fn() { xxx ; return whatever; }
I just had a short discussion with Iain about this and implementing this is not as simple as it seems.
First of all static has many meanings in D, but the C meaning of translation unit local function is not one of them ;-)
So marking these functions as private seems intuitive. After all, if you can't access a function from outside of the translation unit and you never leak an address to the function why not remove it? It could be either completely unused or inlined into all callers in this case.
Now here's the catch: We can't know for sure if a function is unused:
private void fooPrivate() {}
/*template*/ void fooPublic()()
{
fooPrivate();
}
When compiling the file GDC knows nothing about the fooPublic template (as templates can only be fully analyzed when instantiated), so fooPrivate appears to be unused. When later using fooPublic in a different file GDC will rely on fooPrivate being already emitted in the original source - after all it's not a template so it's not being emitted into the new module.
There might be workarounds but this whole problem seems nontrivial. We could also introduce a custom gcc.attribute attribute for this. It would cause the same problems with templates, but as it's a specific annotation for one usecase (unlike private) we could rely on the user to do the right thing.
I've got a library that defines something like this:
//singleton.hpp
class Singleton
{
public:
static Singleton* getInstance()
{
static Singleton* mInstance=0;
if (!mInstance)
{
mInstance=new Singleton();
}
return mInstance;
}
};
I include this header when building a couple of shared object libraries. When I build these shared object libraries with gcc (Ubuntu), the static gets marked as unique:
(nm output)
0000000000045780 u Singleton::mInstance
When I build the shared libraries with clang the same symbol gets marked as weak:
0000000000045780 V Singleton::mInstance
When I dlopen(..., RT_NOW) the gcc-built shared objects, the dynamic linker fixes everything up and seems to make a single mInstance symbol. However, when I dlopen(..., RT_NOW) the clang-built shared objects, I get a separate symbol for each library, which makes the singleton not a singleton. Is this expected behavior? Is there some way I can force the dynamic linker to behave as if the symbols were marked as unique, as they are with the gcc compilation?
Looks like https://llvm.org/bugs/show_bug.cgi?id=22281
However it is not marked as resolved and doesn't provide workarounds.
I have same Function present in multiple Functional Library, when i call the function in driver script which function will be executed? for both multiple library and multiple function in same Functional Library.
If you have a function with the same name in multiple libraries, then which version will be executed depends on the order in which the libraries are associated to your QTP script.
If you have Library1.vbs and Library2.vbs associated in that order, the function within Library2.vbs will be executed as it will supercede the earlier loaded library.
Arguably you should never have the same function present in multiple libraries though as it can (and will) get confusing when you're trying to debug, maintain or improve your library code.
I write a library, this library includes a function void f() this function is a one line function and when I compile the library to shared object with -O3 gcc optimization flag it is inlined. I call it in a critical place in the code (must be as fast as possible) and I don't want to call it not inlined (hits performance substantially). The problem is that this function is part of the API that my library exposes so when library users link with my library and call this function they get undefined reference linkage error. Is there a way for my code to use the function inlined but still instantiate it in the object file so library users will be able to link and use it? (When I say "instantiate it in the object file" I mean I'd like to see it when I run objdump -t on the shared object). Just to make it clear, I'm not interested in a solution to wrap it with a function
void F() __attribute__((noinline)) { f(); }
Because I have many functions like that and I don't want to keep a copy for every function due to the enormous amount of overhead. I'm looking for a way to tell the compiler to use it inline when the definition is available to it, but still instantiate the function in the object file, so library users can link to with it too.
Check out this How can I tell gcc not to inline a function?
I found this solution the most appropriate. I'd like to note the main thing is that the code inside the library is still inlined so there is no performance penalty but users can still use the API as all functions have instantiation
Also another possible solution in the compilation level is to use -fkeep-inline-functions gcc switch which also instantiates inline functions and and uses them inlined where possible (unlike -fno-inline switch). The main problem with this switch is that if your code is heavily templated compilation time is much longer and the binary product becomes much bigger
I'm using C++11 compiler to generate embedded code and I'd like to use lambda functions in it. However I need to put the actual generated code for my lambda functions in a different section or always inline it into the function/method where it is used (by default if some lambda function is not inlined it is put into '.text' section). Is there a way to set section attribute for the lambda function? Alternatively is there a way to make GCC compiler always inline lambda functions?
This will put the lambda in the .mylambdas section
auto myLambda = [&]() __attribute__((section(".mylambdas"))
{
...
};
Note : There's a bug with gcc where it complains if you use the same section name for lambdas in both regular class methods and const class methods. Clang is ok. One workaround is to use another section name for const methods, if that's possible.