On Mon, Nov 30, 2009 at 11:34 AM, Adam Jackson <[email protected]> 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 _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
