Question about importing symbols
Timothy Normand Miller
theosib at gmail.com
Mon Nov 30 10:55:06 PST 2009
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
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?
Timothy Normand Miller
Open Graphics Project
More information about the xorg-devel