[Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines

[José Fonseca]

On Sat, Jun 15, 2013 at 8:05 PM, Carl Worth <cworth at cworth.org> wrote:

> José Fonseca <jfonseca at vmware.com> writes:
> > FYI, with
> >
> https://github.com/apitrace/apitrace/commit/7700f74f294a28e57860487b917c8807156b3ad1
> > apitrace no longer crashes with Steam overlay.
>
> Thanks, José! This will be quite handy. And it's a fix I'd been hoping
> to make for apitrace, but hadn't gotten around to.
>
> It's also nice to see that you got __libc_dlsym working. When I wrote a
> similar dlsym wrapper for fips I think I tried that but didn't get it to
> work for some reason. (I ended up with something that feels more fragile
> by calling dlvsym to find "dlsym".) So I'll revisit this with the
> apitrace code in mind.
>
> > But the overlay's rendering is not shown/captured when when apitrace
> > uses LD_PRELOAD.
>
> Do you know why this is?
>

No, I don't have a clear understanding.

There are many ways where multiple LD_PRELOAD objects can interfere with
each other (beyond the problem found). If all preload .so did
dlsym(RTLD_NEXT, "foo") then they would probably nest safely. But given we
need to intercept dlsym and/or dlpen, plus functions like glxGetProcAddress.

Even if they nested properly, depending on the ordering of apitrace vs
overlay one might get the overlay working but not actually recorded on file.

But I get the feeling that something is triggering the Steam overlay to not
activate at all.

> I'd definitely be interested in making apitrace work more transparently
here.

Me too. But there are so many apps that only work well with
LD_LIBRARY_PATH, that make think that the best way forward is not to keep
adding hacks for LD_PRELOAD to work, but rather making apitrace seemingly
use LD_LIBRARY_PATH out of the box.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130616/9ecd5ddf/attachment.html>