Enforcing server and API in a dlloader world

[Egbert Eich]

So far the module loader has had the policy to only expose those symbols 
from the core part of the server to modules that where specified in the 
sym-files you have mentioned while it exposed any symbol inside a module 
that was non-static to every other module. 
It would be nice if we could preserve the former behavior so that we
would be able to keep the symbols to export from the core in a single 
place while we come up with a more restrictive behavior than the
latter one.
If we could turn the list of symbols into a map file while we use the
apporach of specifying the symbols to export inside the code itself
for the modules we have a solution which would preserve as much as
possible of the resent behavior.

Cheers,
	Egbert.

Adam Jackson writes:
 > A quick backgrounder.  The server exports a list of public API symbols to the 
 > loadable modules.  This list is composed from a few tables maintained in 
 > hw/xfree86/loader/*sym.c.  When using elfloader (or indeed aout- or 
 > coffloader), when you're in a loadable module, this table is the only way to 
 > resolve symbols from the server.
 >  
 > dlloader is more forgiving.  The system linker will allow you to get at any 
 > symbol from the server's core that happens to have global visibility, and 
 > dlloader's resolution code doesn't look at X's symtabs at all.  In practice, 
 > this means that every variable and function not declared static is visible to 
 > the modules.   Obviously that won't be acceptable going forward, because C's 
 > scoping rules are too coarse-grained to enforce the API contract we'd like.
 > 
 > So there's two ways out of this.  One is linker maps, and the other is 
 > explicit visibility tagging.  With tagging, you set the symbol's desired 
 > visibility as part of the definition in the source.  With maps the linker 
 > filters down symbol visibility during the link stage.  Linker maps are 
 > slightly more widely supported, but tags are processed at compile time and so 
 > have potential benefits in code generation.  I'm a fan of tags, personally, 
 > as the code size reduction on gcc/x86 systems is usually between 5% and 10% 
 > and calls to the hidden functions get cheaper by about the same margin.  For 
 > egregiously large modules like GLcore this is a big win.
 > 
 > So anyway, bug #3360 adds some new #defines for this for the gnu and sun 
 > compilers (the only ones where I know the magic words).  The way I did this 
 > optimization in Mesa was to explicitly mark the public API, so that when the 
 > compiler is invoked with -fvisibility=hidden (or its equivalent) you just 
 > win.  The other approach is also possible, of marking those functions you 
 > definitely want hidden.  #3365 has an example of that for XAA.
 > 
 > I plan on implementing the tag method, and not the linker map method.  I could 
 > probably be talked into adding linker maps as well, but probably not talked 
 > into doing linker maps exclusively.  The server's API definitely needs to be 
 > enforced to match elfloader's semantics.  The modules are harder to nail down 
 > exactly what their API should be, so that may remain an open issue for now 
 > (although in the XAA case I'm all about making it as hard as possible to do 
 > new things with it).
 > 
 > Comments welcome.  Particularly from people who are supplying closed drivers, 
 > no need to make this any harder for you than necessary.  I hate the closed 
 > driver game, but we're stuck with it for now.
 >