KHR_debug & eglGetProcAddress()

On PVRVFrame 3.3, KHR_debug is advertised. However, eglGetProcAddress( “glDebugMessageCallbackKHR” ) fails (returns a NULL pointer). Same thing with eglGetProcAddress(“glDebugMessageCallback” ), even though that’s not the name for a KHR extension function.

Digging into PVRVFrame 3.3’s libGLESv2.dll for clues, I find “_glDebugMessageCallback@8” (i.e. “glDebugMessageCallback()”, with C naming and an explicit stdcall calling convention: i.e. __declspec(dllexport) void __stdcall)).

So why can I not query this function with eglGetProcAddress() using PVRVFrame 3.3?

As an aside, I note that in the PVRVFrame 3.4 libGLESv2.dll, the glDebugMessageCallback() is C++ name-mangled ("?glDebugMessageCallback@@YGXP6GXIIIIHPBDPBX@ZPAX@Z"). What’s going on there?

Hi Dark_Photon

This is a bug caused by a disagreement between EGL and GLES with regards to the ‘KHR’ suffix.

Unfortunately I don’t think we have a workaround for aquiring the function pointers but it will be fixed in the next release. We’ve also added visualizations to the GUI for debug groups and stuff and generally given KHR_debug some overdue attention.

Thanks, Chris. I appreciate you checking into it. If I get back to working with this, I might be able to bandaid around this by compile-time linking with the symbol directly and/or pulling in the symbol with explicit dlsym/LoadLibrary*.


has this problem been solved and what is currently the correct way to retrieve the debug callback function pointers?

Hi desperado,

The issue was tackled. You can use eglGetProcAddress to retrieve a function pointer to glDebugMessageCallbackKHR. The syntax should be something similar to:




1 Like

© Imagination Technologies Limited. All rights reserved.
Privacy PolicyTerms & ConditionsTrademarksCookies