KHR_debug & eglGetProcAddress()

This topic contains 2 replies, has 2 voices, and was last updated by  Dark_Photon 2 years, 9 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #31921

    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*.

Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic.