According to the documentation glProgramParameteriARB is a part of ARB_geometry_shader4. I have a graphics card which doesn't support ARB_geometry_shader4:
glxinfo | grep ARB_geometry_shader4
When I call glXGetProcAddress((const GLubyte*)glProgramParameteriARB) I get a function address and everything works fine. Does it mean that the documentation has a bug ? How can I find an extension which contains glProgramParameteriARB ?
glXGetProcAddress can be called without having a current OpenGL context (unlike wglGetProcAddress). As such, the function pointers it returns are independent of the current context. Because of that, it will return valid function pointers for any OpenGL function. It uses delayed binding for this kind of stuff.
If you want to know whether you can use a function pointer, check the extension strings, not whether you get a valid pointer.
Related
I want to get the address from a value in the same way that the x examine command works. Internally, this seems to use value_as_address, which turns any gdb expression into a core address. I have not managed to find a binding for this anywhere in the Python API surface. Further, the workarounds I've seen so far don't seem to accomplish this:
It is not reasonable to cast the type to a void pointer because this is language dependent (will not work in Rust executables, for instance):
some_Value.cast(gdb.lookup_type('void').pointer())
will fail if there is no "void" type, as in the case of Rust.
I want to accept integers, which should come out unchanged.
In particular, I want a function that takes strings such as "0x5555555740a0", "main", etc and turns them into an integer containing their address.
I'm working on learning OpenGL development and while working through some example source code there's a line that I can't seem to make sense of. It involves initialization of GLAD with GLFW. Below is the whole block of code.
if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))
{
std::cout << "Failed to initialize GLAD" << std::endl;
return -1;
}
So, as far as I can tell, the code in the if statement is designed to initialize GLAD and return a 1 if the initialization is successful allowing easy error handling. Cool. Where I am confused though, is the input to this gladLoadGLLoader function, which is:
(GLADloadproc)glfwGetProcAddress
Doing a bit of research, GLADloadproc returned nothing useful, but glfwGetProcAddress has an entry in the GLFW documentation here, and according this, it is a function and defines 1 required argument. I thought this was weird because in the source code it doesn't even look like a function; it looks like glfwGetProcAddress is a variable (or object perhaps?) being cast to a type of GLADloadproc. Doing a bit of introspection, I ran the following prints:
std::cout << glfwGetProcAddress << std::endl;
std::cout << typeid(glfwGetProcAddress).name() << std::endl;
Output:
00AE1172
void (__cdec*__cdecl(char const *))(void)
So I can see that calling glfwGetProcAddress as it is does in fact return something that looks like an address, but attempting to call it as glfwGetProcAddress() fails and not shockingly needs an argument. And when looking at the type of this supposed address it is something I definitely do not understand. So I'm fine with using this as clearly it works and is referenced directly in official documentation as well as tutorials, but I'd really like to understand what's going on here if anyone happens do have a better idea than I do.
OpenGL extensions (and on some operating systems every function not defined in the OpenGL 1.1 profile) have to be loaded at runtime. This means that one has to query the address of each of these functions through the appropriate operating system api (wgl/glx/...). The result is than a function pointer that can be used to call the function.
GLAD is now a library that handles this function pointer loading for you. But in order to be able to query the function pointer it needs to know which method should be used to retrieve them (as already said, this is operation system/window api dependent). The first argument to gladLoadGLLoader is a function pointer to a function used to retrieve OpenGL function pointer by name. gladLoadGLLoader then calls this function (pointer) to query other function pointer.
In case of glfw, the function used is glfwGetProcAddress but one could also pass glutGetProcAddress when working with glut or SDL_GL_GetProcAddress when working with SDL.
typedef void* (* GLADloadproc)(const char *name);
That's not just any old pointer type: that's a function pointer type. In your code, you call the function gladLoadGLLoader, but pass the address of glfwGetProcAddress. gladLoadGLLoader now gets to call the argument you passed it, any time it wants to, and with whatever argument it wants to. You yourself are not actually calling glfwGetProcAddress.
In this context, glfwGetProcAddress is a 'callback', and gladLoadGLLoader registers that callback.
I would like to use FsRtlIsDbcsInExpression (https://msdn.microsoft.com/en-us/library/windows/hardware/ff546803(v=vs.85).aspx) to do wild card checking exactly the same as Windows does it natively without have to re-implement it in my program. When I use:
auto module = GetModuleHandle(TEXT("NtosKrnl.exe"));
module turns up null. From what I can find on the internet, since this is a kernel mode function, KernelGetModuleBase is required. However, this function doesn't seem to resolve automatically and there are no msdn docs on it, so I am doubtful that is the solution. Does anyone have pointers for how to use function?
GetModuleHandle for ntoskrnl is going to fail because it's not loaded into your memory space. You can only call such functions from kernel.
You might want to try for the function PathMatch spec (https://msdn.microsoft.com/en-us/library/windows/desktop/bb773727%28v=vs.85%29.aspx). It appears to do the same job.
I have been playing around with pointers and function pointers in c/c++. As you can get the adress of a function, can you change where a function call actually ends?
I tried getting the memory adress of a function, then writing a second functions adress to that location, but it gave me a access violation error.
Regards,
Function pointers are variables, just like ints and doubles. The address of a function is something different. It is the location of the beginning of the function in the .text section of the binary. You can assign the address of a function to a function pointer of the same type however the .text section is read only and therefore you can't modify it. Writing to the address of a function would attempt to overwrite the code at the beginning of the function and is therefore not allowed.
Note:
If you want to change, at runtime, where function calls end up you can create something called a vritual dispatch table, or vtable. This is a structure containing function pointers and is used in languages such as c++ for polymorphism.
e.g.:
struct VTable {
int (*foo)(void);
int (*bar)(int);
} vTbl;
At runtime you can change the values of vTbl.foo and vTbl.bar to point to different functions and any calls made to vTbl.foo() or .bar will be directed to the new functions.
If the function you're trying to call is inlined, then you're pretty much out of luck. However, if it's not inlined, then there may be a way:
On Unix systems there's a common feature of the dynamic linker called LD_PRELOAD which allows you to override functions in shared libraries with your own versions. See the question What is the LD_PRELOAD trick? for some discussion of this. If the function you're trying to hijack is not loaded from a shared library (i.e. if it's part of the executable or if it's coming from a statically linked library), you're probably out of luck.
On Windows, there are other attack vectors. If the function to be hooked is exported by some DLL, you could use Import Address Table Patching to hijack it without tinkering with the code of the function. If it's not exported by the DLL but you can get the address of it (i.e. by taking the address of a function) you could use something like the free (and highly recommended) N-CodeHook project.
In some environments, it is possible to "patch" the beginning instructions of a function to make the call go somewhere else. This is an unusual technique and is not used for normal programming. It is sometimes used if you have an existing compiled program and need to change how it interacts with the operating system.
Microsoft Detours is an example of a library that has the ability to this.
You can change what a function pointer points to, but you can't change a normal function nor can you change what the function contains.
You generally can't find where a function ends. There's no such standard functionality in the language and the compiler can optimize code in such ways that the function's code isn't contiguous and really has not a single point of end and in order to find where the code ends one would need to either use some non-standard tools or disassemble the code and make sense of it, which isn't something you can easily write a program for to do automatically.
I want to modify the glBindTexture() function to keep track of the previously binded texture ID's. At the moment i just created new function for it, but then i realised that if i use other codes that use glBindTexture: then my whole system might go down to toilet.
So how do i do it?
Edit: Now when i thought it, checking if i should bind texture or not is quite useless since opengl probably does this already. But i still need to keep track on the previously used texture.
As Andreas is saying in the comment, you should check this is necessary. Still, if you want to do such a thing, and you use gnu linker (you don't specify the operating system) you could use the linker option:
--wrap glBindTexture
(if given directly to gcc you should write):
-Wl,--wrap,glBindTexture
As this is done at linker stage, you can use your new function with an already existing library (edit: by 'library' I mean some existing code which you can recompile but which you wouldn't want to modify).
The code for the 'replacement' function will look like:
void * __wrap_glBindTexture (GLenum target, GLuint texture) {
printf ("glBindTexture wrapper\n");
return __real_glBindTexture (target,texture);
}
You actually can do this. Take a look at LD_PRELOAD. Create a shared library that defines glBindTexture. To call the original implementation from within the wrapper, dlopen the real OpenGL library and use dlsym to call the right function from there.
Now have all client code LD_PRELOAD your shared lib so that their OpenGL calls go to your wrapper.
This is the most common method of intercepting and modifying calls to shared libraries.
You can intercept and replace all calls to glBindTexture. To do this you need to create your own OpenGL dll which intercepts all OpenGL function calls, does the bookkeeping you want and then forward the function calls to the real OpenGL dll. This is a lot of work so I would defintely think twice before going down this route...
Programs like GLIntercept work like this.
One possibility is to use a macro to replace existing calls to glBindTexture:
#define glBindTexture(target, texture) myGlBindTexture(target, texture)
Then in you code, where you want to ensure against using the macro, you surround the name with parentheses:
(glBindTexture)(someTarget, someTexture);
A function-like macro is only replace where the name is followed immediately by an open-parenthesis, so this prevents macro expansion.
Since this is a macro, it will only affect source code compiled with the macro visible, not an existing DLL, static library, etc.
I haven't ever worked with OpenGL, so not knowing anything about that function, here's my best guess. You would want to replace the glBindTexture function call with your new function's call anywhere it occurs in your code. If you use library functions that will call glBindTexture internally, then you should probably figure out a way to reverse what glBindTexture does. Then, anytime you call something that binds a texture, you can immediately call your reversal function to undo its changes.
The driver WON'T do it, it's in the spec. YOU have to ensure that you don't bind the same texture twice, so it's a good idea.
However, it's even a better idea to separate the concerns : let the low-level openGL deal with its low-level stuff, and your (thin, thick, as you want) abstraction layer do the higher-level stuff.
So, create a oglWrapper::BindTexture function that does the if(), but you should not play around with LD, even if this is technically possible.
[EDIT] In fact, it's not in the ogl spec, but still.
In general, the approaches have been catalogued under the heading of "seams", as popularized in M. Feather's 2004 book Working Effectively with Legacy Code. The book focuses on finding seams in a monolith application to isolate parts of it and put them under automated testing.
Feathers' seams can be found in the following places
compiler
__attribute__ ((ifunc in GCC, https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html
preprocessor
change what gets used with a #define
linker
-Wl,--wrap,func_xyz
linking order, first found symbol gets used, program can delegate using dlsym(RTLD_NEXT, ...)
the binary format has a Procedure Linkage Table which can be modified by the program itself when it runs
in Java, much can be achieved in the JVM, see for example Mockito
language features
function pointers, this can actually be done so as to add no syntactic overhead at point of call!
object inheritance: inherit, override, call super()
sources:
https://www.informit.com/articles/article.aspx?p=359417&seqNum=3
https://www.cute-test.com/guides/mocking-with-cute/