[Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

Jason Ekstrand jason at jlekstrand.net
Sat Aug 6 14:24:49 UTC 2016


On Aug 6, 2016 4:00 AM, "⚛" <0xe2.0x9a.0x9b at gmail.com> wrote:
>
> On Sat, Aug 6, 2016 at 4:34 AM, Rob Clark <robdclark at gmail.com> wrote:
> > On Fri, Aug 5, 2016 at 8:42 PM, Jan Ziak <0xe2.0x9a.0x9b at gmail.com>
wrote:
> >> Mesa source code prior to this patch uses both RTLD_NOW and RTLD_LAZY.
> >> This patch removes all RTLD_NOW in favor of RTLD_LAZY.
> >>
> >> In comparison to early binding, lazy binding reduces CPU instruction
count
> >> of small GL apps (e.g: glxinfo) by 6 million instructions.
> >> Larger apps won't notice the difference.
> >
> > tbh, I don't know the background of existing places that use RTLD_LAZY
> > instead of RTLD_NOW (but my experience w/ xserver using LAZY has not
> > been positive, so I think going the other direction seems like a good
> > idea)..
>
> We could add a verifier to the build process that tests the foo_dri.so
> libraries (as well as all other libs subject to dlopen by Mesa) for
> undefined symbols:
>
> $ LD_PRELOAD=libGL.so ldd -d -r radeonsi_dri.so \
>     | grep "^undefined" && echo "red alert!"
>
> This will ensure that Mesa does not break apps after replacing all
> RTLD_NOWs with RTLD_LAZY.
>
> I am going to start writing a new patch verifying relevant *.so files
> at buildtime.

Yes please. Regardless of whether or not we use RTLD_LAZY, I would like
undefined symbols to produce a build error rather than a runtime error you
need extra environment variables to debug.

> > But I'm not sure that optimizing for glxinfo is the best goal.
>
> I will turn my attention to manifestations of suboptimal Mesa GL in
> other apps as soon as I am satisfied with glxinfo/glxgears (and after
> the list of my patches at patchwork gets closer to zero).
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160806/1c16da5a/attachment.html>


More information about the mesa-dev mailing list