Enforcing server and API in a dlloader world
Adam Jackson
ajax at nwnk.net
Sun May 22 12:24:16 PDT 2005
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/attachments/20050522/f5c9931a/attachment.pgp>
More information about the xorg
mailing list