RFC/WIP: Retracing without explicitly linking to libGL

Alexandros Frantzis alexandros.frantzis at linaro.org
Thu Dec 1 08:52:52 PST 2011


Hi all,

in the spirit of what was previously discussed, I am working on a branch
that implements a scheme allowing the retracers to avoid explicitly
linking with libGL:

http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/retrace-no-link-gl-wip

This patchset first adds a glws::getProcAddress() function that
implements the logic to get a GL/EGL/... function pointer, by first
trying the system mechanism for getting symbol addresses (dlsym etc),
and then by using the *GetProcAddress() functions.  The implementation
for each system is based on the snippets in *trace.py. The code retains
the approach of first searching in the already linked libraries and
then, if needed, trying to dlopen() the right GL library.  For the
EGL/X11 case, the right library is selected based on the current
context/profile. I have added sample implementations for Cocoa and
Win32, too, but as I don't have access to such systems, these two are
completely untested.

The patchset also changes the way glproc.hpp is produced for retracing.
In particular, it emits __* dispatchers for *all* processed functions,
and uses the glws::getProcAddress() function to get the address of both
"public" and "private" symbols. Due to the way glws::getProcAddress()
works, the "private" vs "public" distinction does not make much sense.

Finally, the patchset ensures that eglretrace doesn't explicitly link
with libGL, and that any needed libraries are indeed linked with (i.e.
marked as NEEDED in the SO) even when none of their symbols are
explicitly used. This is important primarily for libEGL at the moment.
Of course, if we choose to do so, we can handle libEGL in the same way
that we handle libGL, i.e., not require explicit linking.

Note that, besides a small fix for proper compilation, the need for
different state dumping mechanisms for GLX/GL vs EGL/GL* is not
addressed at all by this patchset.

Thanks,
Alexandros


More information about the apitrace mailing list