Question about importing symbols

[Adam Jackson]

On Wed, 2009-11-25 at 16:33 -0500, Timothy Normand Miller wrote:

> My question:
> 
> I added fbCreateWindow to the list of symbols to be imported by
> xf86LoaderReqSymLists, but I still get an error that fbCreateWindow is
> undefined.  I have successfully imported some other functions
> (fbScreenInit, fbPictureInit, fbCreateDefColormap), but this one isn't
> playing nice.  Is there something I'm missing here?  Do I have to make
> a call to fb or something in the server core to get it to export that
> symbol so that I can then import it?

Man am I glad this code went away.

The symbol requirement/reference list actually meant something back in
pre-dlloader days, but since then it's basically bookkeeping.  (Except
in current servers, where it no londer exists.)  In a dlloader world,
the symbol lists do not actually change the availability of symbols
across modules.  All they do is give the server the ability to error
(fatally) early if you claim to require a symbol but have not loaded it
yet.

The "required" list is the list of symbols to error fatally on.  The
"referenced" list is the list to _not_ error fatally on, presumably
because you know when you're being careful with them.

Now, I'm not completely clear how you're getting to this error path at
all.  LoaderCheckUnresolved() is called after your ScreenInit hook, so
you should have fb loaded by that point.  We do call the
CheckForUnresolved hook for each loader backend (which I think should
give you just elfloader and dlloader), but for dlloader that's a nop and
for elfloader it _should_ be effectively a nop since there shouldn't be
any elfloader relocations.  ELFCheckForUnresolved is the only thing that
should be calling _LoaderHandleUnresolved, which is the only thing that
sets fatalReqSym to trigger the fatal error path.  So, hm.

But, you should be able to make it non-fatal by taking the symbol out of
the 'req' list and putting it in the 'ref' list.

> What other symbols am I going to have trouble getting access to?  I
> heard that there's an alternate way to look up symbols by name.  The
> performance on that is probably lousy, but I can do a bunch on init
> and store them in a structure if necessary.

The lookup cost is not much worse than that of dlsym().  The runtime
performance ends up being slightly better than direct symbol calls
because you're not banging through the PLT every time.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20091130/cc53758e/attachment.pgp