Lowell, Randy wrote: > Rod, > > At HP we're only using 2-bits of st_other, so the proposed definitions > do not clash with our current implementation, however I am also interested > in hearing the proposed runtime model for handling STV_SINGLETON. A > model that requires examination of every definition instance is less > efficient than one that only requires locating the "first" definition. > How do you handle a dlopen that introduces a new STV_SINGLETON instance > when there are already multiple bindings to other instances of the same > symbol?
I think I covered most of this in my response to Dave Prosser. A dlopen, or any new module loaded, can contribute a singleton Any reference to a singleton will follow a simple search of each loaded object, regardless of how the object was loaded. Thus, if a dlopen'd object referenced a singleton I'd expect it to jump out of the dlopen hierarchy and follow the simple search. Another way to view this might be to think of interposers. Folks having been using techniques like LD_PRELOAD to interpose on existing symbols for years. All references to symbols defined in an LD_PRELOAD object are bound to the preloaded object. Singletons provide a similar capability where the binding requirements are an attribute of the symbol and are controlled by the code generators rather than the user having to set some environment variable or such. In a process where multiple instances of a singleton symbol exist, all references to these symbols bind to the first definition - interposition! > Our compiler makes certain assumptions about symbols that it marks as > STV_PROTECTED and STV_HIDDEN. Based on those assumptions it can > optimize references to those symbols. STV_SINGLETON could not safely > override limited visibilities, because it would break those assumptions. Correct. It would be a fatal linking error to come across the same symbol name with a STV_SINGLETON and any other visibility besides STV_DEFAULT. Although this resolution differs from what we presently handle (ie. the most restrictive visibility is taken), catching a flagrant incomparability isn't any different from the link-edit already catching "foo()" in one object and "foo[]" in another object as questionable :-) Thank you for your comments. -- Rod
