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

[Jan Vesely]

On Sat, 2016-08-06 at 17:34 +0200, ⚛ wrote:
> On Sat, Aug 6, 2016 at 4:32 PM, Jan Vesely <jan.vesely at rutgers.edu>
> wrote:
> > 
> > On Sat, 2016-08-06 at 13:00 +0200, ⚛ wrote:
> > > 
> > > 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.
> > 
> > This won't help at all. the linking process already includes no-
> > undefined flag, so the build will fail at linking stage if symbols
> > can't be resolved.
> 
> You are wrong about --no-undefined being used for *_dri.so. Grep your
> Mesa build log for "-o .libs/gallium_dri.so" and then send an email
> with your opinion please.

(ignoring the uncalled for display of arrogance)

it does not change the fact that -Wl,--no-undefined is the tool to
catch unresolved symbols, instead of introducing a custom tool.

to be more constructive. The situation I'm concerned about is as
follows:
1.) mesa builds fine using existing build environment.

2.) I update LLVM. This update changes symbols (function parameter
changed type, a function was moved to header, or devirtualization pass
did a better job, ...)

I want to know whether this happened and mesa rebuild is necessary.

surely most llvm symbols are used immediately, but if optimizations
like shader cache are present it can take some time before the compiler
path is exercised, postponing failed symbol lookups well into the
future.

Jan
> 
> > 
> > RTLD_NOW detects bugs in deployment. IMO it's preferable if DE
> > fails to
> > start instead of crashing hours into work. sure I can set
> > LD_BIND_NOW
> > env var, but there are programs that have much stronger case for
> > using
> > lazy binding (like LO) that would be negatively affected.
> > 
> > shaving 6M instructions does not seem like strong enough benefit to
> > justify this.
-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160806/eec47a3f/attachment.sig>