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
Related
I'm trying to figure out how Windows manages to map the memory of a PE file into the address space, so I've seen something that makes me confused.
Let's say we have something like this:
HMODULE some_module = GetModuleHandleA(NULL);
int main() { // Or DllMain doesn't matter
// some operations using some_module or whatever
return 0;
}
The initialization of some_module is performed before entry point is called. I'm trying to implement this looking into the PE file (I found the initialization functions), but only thing I can see is that those initialization functions are used as RUNTIME_FUNCTION, nothing else. How can I extract those initialization functions among all the runtime functions and call them manually? Are there any documentation about this? I also tried a function called RtlAddFunctionTable but I think it's not made for that. What kind of operations can performed to implement that? Thanks.
Problem is solved, was about a different thing. But I had some research and see that those entries (runtime functions, includes static initializations) are already called in entry point. Those functions are specified as some memory range and called by a function called "ucrtbase!initterm" (or "ucrtbase!_initterm"). In some PE files that initterm function is compiled as a new function, instead of using an import from ucrtbase. And finally, those functions are called in an order of where they're located in memory (lower-address -> upper-address).
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.
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 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.
In my previous question, I asked why I kept getting the error message bad DLL calling convention when trying to call functions from a DLL. The general consensus was that I needed to change the calling convention to cdecl. Makes sense.
Unfortunately, I cannot place it right there on the function declaration importation. I had to either "create a wrapper DLL" or "create a type library for the DLL."
I am very unfamiliar with VB as my main focus at work is C# and this is the first time working in the language for a very long time. I'm not sure exactly how to accomplish this task.
I'm also confused as to how a wrapper DLL helps things. Supposedly I can't decorate a function import with cdecl in my code but if I move that exact function import to a new VB6 DLL and then reference that DLL it suddenly works?
I actually think this question was better on the topic.
To sum up, you can "place it right there on the function declaration importation", but the VB6 IDE doesn't know how to debug such a thing. But the compiler deals with it just fine. Once you compile it into a dll then your main project can access the functionality that was compiled.
Perhaps you are asking how to move these into a dll? If that is the case, you need to create a new Project of type "ActiveX Dll". Name it something like PwrUSB. Next, add a class (or rename the default/empty one if it is provided) to something like PwrUSBApi. Next, in the properties window, set the class to GlobalMultiUse. In a module called MDeclares, drop in all of your declarations:
'from your other post...
Public Declare Function InitPowerDevice CDecl Lib "PwrDeviceDll.dll" (ByRef firmware() As Byte) As Long
Back in your PwrUSBApi class:
'forward your calls to the dll
Public Function InitPowerDevice (ByRef firmware() As Byte) As Long
InitPowerDevice = MDeclares.InitPowerDevice(firmware)
End Function
You could create a more fully fledged object model from the API, but I'd start with this simple wrapper until you sort out all of the APIs.
Oh yeah, back in your main project you'd add a reference your new wrapper PwrUSB.dll in the Project menu. Then in the code you would use it something like this:
Dim numOfDevices as Long
Dim firmware() As Byte
Redim firmware(0 to 31)
numOfDevices = PwrUSB.InitPowerDevice(firmware)
Good luck.
A wrapper DLL in VB6 would still need to use the CDecl decorator or else a typelib created to deal with the DLL's function signatures.
The only advantage in creating a VB6 wrapper for this is to make it easier to debug the calling program from within the VB6 IDE, where CDecl has no effect. The wrapper would be small, and created once as a native code DLL, making CDecl effective there.
See your other thread(s) for additional answers. I suspect your real problem is that you were not passing the right kind of argument.