I have created a static library (.lib). The source code looks like this:
Source file:
void foo(void)
{
MyType var;
var.val1 = 40;
var.val2 = 30;
use(var);
}
Header filer (libheader.h):
/* Exported API */
void foo(void);
Main project:
#include "libheader.h" // XX.lib already imported to the main project
int main()
{
// some code
foo(); // Breakpoint here and step in
// some code
return 0;
}
In the main project, I imported the library and included "libheader.h" and I called foo(). When I debug my code and I put a breakpoint on foo()then I click on 'Step in' the assembler code of the static library is shown in the debug console and I can see local variables content like var (in the example). I can even see in the call stack that use(var) has been called.
My question is: This library should be protected before being delivered to the client. Is it normal that the content (variables, function names, calls ...) of a .lib file can be seen during debug? Is there a way to crypt/protect it?
Related
I am trying to instrument the linux kernel code to insert a function call in every function right after a BitCast instruction.
So I modify the C code to #include <linux/my_header.h> where I have my printer function.
The header looks something like this.
#ifndef __header_ID
#define __header_ID
static inline void print_typecast(...){
printk(...);
}
#endif
Then I use Xclang to load my FunctionPass, which looks something like this.
// M is of type llvm::Module*
Function* f = M->getFunction("print_typecast");
if (f == nullptr) {
errs() << "Function not found in the module\n";
}
else {
// insert function in the code
}
However, my pass never finds the function in the module. When I remove the static it will find the function but then the linker in the final compilation step will complain of duplicate definition.
Anyone knows how to make LLVM "see" static imported/included functions?
Edit: I have also gone to the extreme where I have the same function directly written in every c file of the kernel code (the ones that #include <linux/kernel.h>)
static means that all calls to this function will be visible to this compiller now, and by implication that if the compiler sees no such calls, then it can skip compiling any output for the function, because you as programmer have promised that noone will want it.
I would like to build a .dll filled with Lua bindings written in C compiled using VS 2017, but I don't seem to be having any luck, and the resources available to me are confusing and, by majority, outdated.
Here is what I've done.
I've already compiled lua from source and added it to my path so that I can lua.exe anything. This also created lua53.dll.
I've taken all of the .c and .h files of the lua source and added them to my VS project, along with one main.c which I am using to test. I added the .dll file as well, but only in the same way that I added the .c and .h files. I don't think it's doing anything.
Here's main.c:
#define LUA_LIB
#include "lua/lua.h"
#include "lua/lualib.h"
#include "lua/lauxlib.h"
#include "tg/tg.h"
static int lua_TG(lua_State *L) {
return 1;
}
static int lua_useTGHandle(lua_State *L) {
struct TGHandle *tgHandle = malloc(sizeof(struct TGHandle));
*tgHandle = TG();
lua_pushlightuserdata(L, tgHandle);
return 1;
}
static const luaL_Reg tglib[] = {
{"TG", lua_TG},
{"useTGHandle", lua_useTGHandle},
{NULL, NULL}
};
LUALIB_API int luaopen_libtg(lua_State* L) {
luaL_newlib(L, tglib);
return 1;
}
One function implemented, one not, but the lib should register.
I have changed the build type to a .dll, and I get the .dll generated without any errors, but when I try to use it in a Lua script I get:
%1 is not a valid Win32 application.
Surely I just have no clue what I'm doing. How would I just set up a lua-binding-building environment in VS2017?
I have a 218KB .dll and a 596KB .so file, both with identical names. I want to link to the .dll to avoid the "unresolved external symbol" error that the linker returns, but I can't find a way to link to the DLL file.
According to this Pelles C forum topic, I need to use the .def file to create a .lib... but I don't have a .def file. This forum topic shows how to use polink to create a .lib from the command line, so I ran polink /? to get some more options. I noticed a /MAKEDEF option, but running this with both the .dll and the .so gives a "No library file specified" fatal error.
I have been trying to do this for three hours, and am out of ideas. I have got to the point where my web searches turn up my own help-requests. There must be a way to do this... How can I link to a .dll?
With information found in the header #include and your details, here is a way to replace the missing function by calling them dynamically from your software.
1- the following prototype is in #include :
typedef float (* XPLMFlightLoop_f)(float inElapsedSinceLastCall, float inElapsedTimeSinceLastFlightLoop, int inCounter, void * inRefcon);
2- some const that you can fill as needed:
const char *sDllPathName = "<Your XPLM_API DLL>.dll";
const char *sXPLMRegisterFlightLoopCallbackName = "XPLMRegisterFlightLoopCallback";
In order to confirm the sXPLMRegisterFlightLoopCallbackName, you can
use the freeware Dependency Walker and check name and format of
the exported functions.
3- declare the prototype of the external function:
Be aware to the calling convention __cdecl or __stdcall
In the current case, the keyword XPLM_API is defined in the XPLMDefs.h as follow:
#define XPLM_API __declspec(dllexport) // meaning __cdecl calling convention
typedef void (__cdecl *XPLMRegisterFlightLoopCallback_PROC)(XPLMFlightLoop_f, float, void *);
4- clone the function to call it in your software:
#include <windows.h>
void XPLMRegisterFlightLoopCallback(XPLMFlightLoop_f inFlightLoop, float inInterval, void * inRefcon)
{
HINSTANCE hInstDLL;
XPLMRegisterFlightLoopCallback_PROC pMyDynamicProc = NULL;
// Load your DLL in memory
hInstDLL = LoadLibrary(sDllPathName);
if (hInstDLL!=NULL)
{
// Search for the XPLM Function
pMyDynamicProc = (XPLMRegisterFlightLoopCallback_PROC) GetProcAddress(hInstDLL, sXPLMRegisterFlightLoopCallbackName);
if (pMyDynamicProc != NULL)
{
// Call the XPLM Function with the orignal parameter
(pMyDynamicProc)(inFlightLoop,inInterval,inRefcon);
return;
}
}
// Do something when DLL is missing or function not found
}
5- just add your described call:
...
XPLMRegisterFlightLoopCallback(callbackfunction, 0, NULL);
...
Is there an equivalent of the following on Windows?
#include <dlfcn.h>
#include <stdio.h>
void main_greeting(void)
{
printf("%s\n", "hello world");
}
void lib_func(void)
{
void (*greeting)(void) = dlsym(RTLD_MAIN_ONLY, "main_greeting");
greeting ? greeting() : printf("%s\n", dlerror());
}
int main(void)
{
lib_func();
return 0;
}
This is a short snippet, the real purpose is to call a function know to exist at a main process (main_greeting), from inside a function (lib_func) from a dynamic loaded library. The main process is not modifiable, and so cannot be rewritten to pass callbacks.
On Windows, executables and DLLs are of the same format (PE nowadays), so an executable can export functions too. GetProcAddress(GetModuleHandle(NULL),TEXT("main_greeting")) will do what you want if the function is exported from the executable. It's done by -Wl,-export-all-symbols for mingw GCC.
I believe there is no equivalent option for Microsoft's linker, so if you use their toolchain, you have to:
export every function with __declspec(dllexport) in source files,
or write a module definition file listing every exported function, passing it to linker,
or generate module definition file automatically.
e.g. In a static library I had
void function (void);
function();
And function() existed in the main application.
But If I build it as a DLL the linker complains that the function is undefined on the DLL.
Yes, but this is hackish.
In the dll :
typedef void(*funcPtr)(void);
// Declare a variable named "ptrFunction" which is a pointer to a function which takes void as parameter and returns void
funcPtr ptrFunction;
// setter for ptrFunction; will be called from the .exe
void DLL_EXPORT setFunction(funcPtr f){ptrFunction f;}
// You can now use function() through ptrFunction
foo(){
ptrFunction();
}
and you call setFunction from the .exe.
void function(){
// implementation here
}
int main(){
setFunction(&function); // now the dll knows the adress of function()
foo(); // calls foo() in dll, which calls function() in the .exe
....
}
Great, huh ? :/
You should probably refactor your code so that function() is in yet another DLL, but it depends.
Yes you can but I would strongly recommend against it if you don't have to. It's fiddly and it feels like you need to sort out your dependencies better.
To do it, you have to use LIB.EXE to create an import library from the object files of one binary before you actually link it; use this import library to link other binary and create an import library for the other binary; finally use the other library's import library to link the original binary.
E.g.
exe.c:
#include <stdio.h>
void __declspec(dllimport) dllfn(void);
void __declspec(dllexport) exefn(void)
{
puts("Hello, world!");
}
int main(void)
{
dllfn();
return 0;
}
Compiler with cl /c exe.c. exe.obj is created.
exe.def:
LIBRARY exe.exe
Create import library with lib /def:exe.def exe.obj. exe.lib and exe.exp are created.
dll.c:
void __declspec(dllimport) exefn(void);
void __declspec(dllexport) dllfn(void)
{
exefn();
}
Compile with cl /c dll.c. dll.obj is created.
Link DLL with link /dll dll.obj exe.lib. dll.dll, dll.lib and dll.exp are created.
Link EXE with link exe.obj dll.lib. exe.exe is created. (exe.lib and exe.exp are also recreated.)
Run exe, note the Hello, world! output.