----- Original Message ----- > On Wed, Feb 27, 2013 at 1:21 AM, Jose Fonseca <jfons...@vmware.com> wrote: > > ----- Original Message ----- > >> Jordan Justen <jordan.l.jus...@intel.com> writes: > >> > >> > Motivated by wanting to see if GenTextures was called by an > >> > application while debugging another Steam overlay issue. > >> > >> Making a systematic MESA_DEBUG=api using dispatch tables and code > >> generation seems like it would be nice instead of adding it ad-hoc. Not > >> something against this patch, just maybe a project for a janitor list if > >> we have one. > >> > >> apitrace seems like it would be to replace it, but I've seen enough apps > >> where it doesn't work (and in this case with the steam overlay it > >> definitely doesn't) that we can't just rely on that. > > > > Could you elaborate on that? I'd like to understand how apitrace would miss > > intercepting calls. > > The Steam overlay uses LD_PRELOAD and there doesn't seem to be a way > to both use the overlay and capture a trace.
I see. But one can use apitrace through LD_LIBRARY_PATH instead of LD_PRELOAD. Steam is not the first app to have issues with LD_PRELOAD. Currently there's no easy way to trace like through LD_LIBRARY_PATH -- one needs to follow the manual instructions in https://github.com/apitrace/apitrace/blob/master/README.markdown#linux but it this does indeed help, then we could add logic to the apitrace trace CLI command to setup LD_LIBRARY_PATH. LD_PRELOAD tends to be more convenient but LD_LIBRARY_PATH should be indistinguishable for applications. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
