I have 2 functions of same name in two different c++ files. Lets say the function name is initialize(char*) and files are file1.cpp and file2.cpp. From gdb how do I call the initialize() function of file file2.cpp. I have tried "call 'file2.cpp'::initialize("setup") but it calls function of file1.cpp.
I verified that same function gets called both times.
This looks like a bug in gdb. You should report it.
This could probably be used as workaround:
print 'file1.cpp'::initialize
print 'file2.cpp'::initialize
(now you have addresses of both functions)
call address-of-one-or-other-function("setup")
Related
I want to instrument some code that gets executed before any other code in my module.
I thought about calling the code in the start of the main function. But there is not always a main function or it is not always named "main". Or it is a library and it doesn't even have a main function.
Are there some other, smarter ways?
You can put the code you want to run early into a function and add that function to llvm.global_ctors. This is the equivalent of using __attribute__((constructor)) in C or C++.
To do this from a pass, you can use the llvm::appendToGlobalCtors function, which is declared in llvm/Transforms/Utils/ModuleUtils.h.
I wrote a function:
function getArtists(where='', artistactive = true){
//yadayada
return artists;
}
and included it, in a template, after the following
<cfstoredproc datasource="#request.dsn#" procedure="GetArtists">
<cfprocresult name="GetArtists">
</cfstoredproc>
This produces an error:
Routines cannot be declared more than once. The routine getArtists has
been declared twice in different templates
Ok, so question 1: ColdFusion thinks that a function and a stored procedure are both 'routines' and cannot be declared twice?
So, next thing I did was to include my functions template before the stored procedure... and it seems to be fine, with that.
Question 2: what gives?
You should believe the error. In testing your code I get no error when declaring the function and then calling a stored proc of the same name. when I dump out the variables scope using <cfdump var="#variables#"> I only see the result set (not the function) because the function has been overwritten by the result set. If I try to call the function after declaring the function and then overwriting it I get "Incorrect entity type for being a function" as my error.
Remember that the CF Compiler goes through your code and compiles UDFs and components first. They are not compiled at runtime. The error you are referencing occurs during the compile, not the runtime. For this reason I think it is more likely that your UDF routine is actually being included more than once. Take a look at the debug information at the bottom and search for that file and see if this is the case - or examine custom tag calls and other ways where files are doubled.
Advice: As a rule UDF should be declared in their own space (onRequest() is a good spot for it) and should be protected from this sort of thing. I use a variable like "lib" and store my functions (which are members of objects just like in Java) as lib.function1(), lib.function2(). The way you are doing it leads to unpredictability. That last is just my Opinion - trying to help. :)
I'm trying to write a forwarding library for libEGL.dll so I can catch calls being passed through it for debug.
The problem is the library is missing 2 methods NvEglGetStdProcAddress and NvEglRegClientApi.
This is a C library built for Arm7 (WinCE). The header file I have for libEGL doesn't include these 2 methods so I have no idea what the signature is in order to forward the calls.
Is there any way of forwarding the calls without knowing the signature?
Could I disassemble the dll and look for the parameters being popped from the stack?
DumpBin shows these at RVA 0x217C and Ox1E5C, /ALL /DISASM shows the .text section starting at 0x11000. How do I translate between these two offsets?
I'm guessing this wouldn't work, Would it just leave the parameters on the stack and then mangle them slightly with the local variable? What would happen to the return value (if there is one?)
typedef void (*NvEglGetStdProcAddressFunc) (void);
void NvEglGetStdProcAddress()
{
NvEglGetStdProcAddressFunc ptr = (NvEglGetStdProcAddressFunc)GetProcAddress(hInst, _T("NvEglGetStdProcAddress"));
ptr();
}
You can simply forward export calls.
So my debug libEGL.dll .def file now has two extra lines at the top of it
; libEGL.def
EXPORTS
NvEglGetStdProcAddress = libEGLOld.NvEglGetStdProcAddress
NvEglRegClientApi = libEGLOld.NvEglRegClientApi
eglBindAPI
eglBindTexImage
...
A colleague of mine tested this and verified it works, although it also requires the ordinal to be specified
In my interpreter I have built-in functions available in the language like print exit input, etc.
These functions can obviously be accessed from inside the language. The interpreter then looks for the corresponding function with the right name in a vector and calls it via a pointer stored with its name.
So I gather all these functions in files like io.cpp, string.cpp, arithmetic.cpp. But I have to add every function to the function list in the interpreter in order for it to be found.
So in these function files I have things like:
void print( arg )
{
cout << arg.ToString;
}
I'd add this print function to the interpreter function list with:
interpreter.AddFunc( "print", print );
But where should I call the interpreter.AddFunc?
I can't just put it there below the print function as it has to be in a function according to the C++ syntax.
Where and how should all the functions be added to the list?
In each module (io, string, etc.), define a method that registers the module with the interpreter, e.g.:
void IOModule::Register(Interpreter &interpreter) {
interpreter.AddFunc( "print", print );
//...
}
This can also be a normal function if your module is not implemented in a class.
Then in your application's main initialization, call the register method of all modules.
This approach helps keep things modular: The main application initialization needs to know which modules exist, but the details of which functions are exported are left to the module itself.
The simplest is to keep a map of function names to function pointers and load that at program startup. You already have the functions linked into the interpreter executable, so they are accessible at the time main() is called.
You can also come up with a scheme where functions are defiled in the dynamic libraries (.dll or .so depending on the platform) and some configuration file maps function names to libraries/entry points.
Is everything included in every interpreter? If so, I would recommend adding it either in a constructor (assuming the interpreter is an object) or an init method.
If not, you may want to consider adding an "include" type directive in your language. Then you do it when you encounter the include directive.
I would like to call a method from an dll, but i don't have the source neither the header file. I tried to use the dumpbin /exports to see the name of the method, but i can found the methods signature?
Is there any way to call this method?
Thanks,
If the function is a C++ one, you may be able to derive the function signature from the mangled name. Dependency Walker is one tool that will do this for you. However, if the DLL was created with C linkage (Dependency Walker will tell you this), then you are out of luck.
The C++ language does not know anything about dlls.
Is this on Windows? One way would be to:
open the dll up in depends.exe shipped with (Visual Studio)
verify the signature of the function you want to call
use LoadLibrary() to get load this dll (be careful about the path)
use GetProcAddress() to get a pointer to the function you want to call
use this pointer-to-function to make a call with valid arguments
use FreeLibrary() to release the handle
BTW: This method is also commonly referred to as runtime dynamic linking as opposed to compile-time dynamic linking where you compile your sources with the associated lib file.
There exists some similar mechanism for *nixes with dlopen, but my memory starts to fail after that. Something called objdump or nm should get you started with inspecting the function(s).
As you have found, the exports list in a DLL only stores names, not signatures. If your DLL exports C functions, you will probably have to disassemble and reverse engineer the functions to determine method signatures. However, C++ encodes the method signature in the export name. This process of combining the method name and signature is called "name mangling". This Stackoverflow question has a reference for determining the method signature from the mangled export name.
Try the free "Dependency Walker" (a.k.a. "depends") utility. The "Undecorate C++ Functions" option should determine the signature of a C++ method.
It is possible to figure out a C function signature by analysing beginnig of its disassembly. The function arguments will be on the stack and the function will do some "pops" to read them in reverse order. You will not find the argument names, but you should be able to find out their number and the types. Things may get more difficult with return value - it may be via 'eax' register or via a special pointer passed to the function as the last pseudo-argument (on the top of the stack).
If you indeed know or strongly suspect the function is there, you can dynamically load the DLL with loadLibrary and get a pointer to the function with getProcAddress. See MSDN
Note that this is a manual, dynamic way to load the library; you'll still have to know the correct function signature to map to the function pointer in order to use it. AFAIK there is no way to use the dll in a load-time capability and use the functions without a header file.
Calling non-external functions is a great way to have your program break whenever the 3rd party DLL is updated.
That said, the undname utility may also be helpful.