Enforcing server and API in a dlloader world

[Adam Jackson]

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.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-arch/attachments/20050522/f5c9931a/attachment.pgp