Question about importing symbols

[Timothy Normand Miller]

On Mon, Nov 30, 2009 at 11:34 AM, Adam Jackson <ajax at nwnk.net> wrote:
> 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.

Here's something interesting we just figured out.  If we do something
like this, we get the unresolved symbol error:

pScreen->CreateWindow = fbCreateWindow;

However, if we CALL the function, we don't get the error.

> 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.

Is that the second pointer argument to xf86LoaderReqSymLists ?

> 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
>

What's the name of the function to call to look up a symbol by name?


Thanks

-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project