[patch] xserver:dri

[Paulo César Pereira de Andrade]

Adam Jackson wrote:
> On Wed, 2009-02-11 at 10:10 -0800, Ian Romanick wrote:
>
>> These are sensible changes, but I don't think it fixes the underlying
>> problem.  The real problem, as you suggest, is that
>> xf86LoaderCheckSymbol is a completely worthless interface.  What is
>> really needed is one of the following:
>
> Only useless for data symbols.
>
>> - xf86LoaderGetSymbol that either returns a pointer to the symbol or
>> NULL.
>
> That's what LoaderSymbol does.  Admittedly it conflates "this symbol
> really is located at address 0" with "this symbol does not exist", but
> in practice this isn't a problem in X.
>
>> - Support for weak symbols from the loader.  For example, if
>> noPanoramiXExtension were weak, there wouldn't be an unresolved symbol
>> error at dlopen.  The error would come if the loaded module tried to use
>> the symbol.

  This would be wrong solution IMO.

> That's not quite what weak symbols do.  Weak symbols have their value go
> to zero (with no error) if a strong symbol of the same name is not
> found.  So there wouldn't be an error if the module tried to use the
> weak symbol's value.
>
> You're welcome to _use_ weak symbols in Xorg.  We're an ELF shop, after
> all.  But for the no*Extension variables, it will give you the wrong
> boolean sense, so it's not a useful thing to do.

  Surely there will be cases where this would be the proper approach,
or at least the easiest one. But I really dislike the idea of weak
symbols in Xorg, at least in the current state. Things can get out
of control easily.

> The problem here is that noPanoramiXExtension is a data symbol.
> Function symbols can be resolved lazily by the runtime linker, because
> there's only one way in the ABI to call a symbol, so you can find all
> the call sites and patch them up to really call a resolver function.
> Data symbols, on the other hand, could be accessed any way you like,
> their addresses mangled by constant folding or any of the other
> optimizations the compiler will do, so there's really no way to fix them
> up after the fact.  So they have to resolve at dlopen time.
>
>     Bool *npe = LoaderSymbol("noPanoramiXExtension");
>     if (npe && !*npe)
>         /* Xinerama is enabled, bail out */
>     else
>         /* either it's disabled or we built without it */

  What should be supported is a "dual" solution. Still support
the LoaderSymbol call as you suggested, and, actually have
noFoobarExtension always available, regardless of the extension
being enabled or not, as well as a few other stub symbols.

  I made some initial coding on this, as well as some other
"related" patches, but I preferred to wait some time, to ensure
the ones I had already applied would not have any major unexpected
side effects (weak symbols can cause major problems with "hidden"
symbols by default, for example :-).

Paulo