On 01/26/10 06:03 AM, Rainer Orth wrote: > Rod Evans<Rod.Evans at sun.com> writes: > >> The compiler engineers have also asked for a means of selecting between a >> family of functions contained within the same dynamic object. Each family >> member is compiled differently to use various capabilities, where these >> capabilities can be provided by different systems. > > Not this case, but how is one supposed to use this directly from the > compiler/assembler without linker mapfiles? Might be interesting to add > support to GCC in the future.
The exact method would be up to the compilers. The high-level idea was that some new compiler option(s) might lead the compiler to generate one or more variants of the functions within a source file. For example, if a source file contained foo(), they might generate a foo%sun4u and foo%sun4v, and associate each function with a set of capabilities that were directed by the compilers options. The generated source file would have the same ELF infrastructure as a relocatable object generated with -z symbolcap. ld(1) could then process this file, as it does now with -z symbolcap generated files, and create the associated dynamic object - no mapfiles need be involved. > A couple of other questions: > > * You're currently using v1 mapfile syntax in the LLM excerpt. I > suppose this is because this case requests patch/micro binding, but it > should state the v2 syntax, too. You've caught us in the middle of two projects, the symbol capabilities and the new mapfile implementation (PSARC/2009/688). The LLM materials for this case don't include changes for 2009/688. However, we have updates for the LLM for 2009/688, and they are being merged together as we speak. The final LLM will have all examples using the v2 syntax. Symbol capabilities can be driven off of v1 or v2 mapfile syntax. > * In the example on p.76 of the LLM, what happens if the machine > provides e.g. both MMX and SSE. Which instance of foo will be used in > this case? I suppose there is a similar ordering like the one > described on p.380 (descending order of capability values), but is > this supposed to be documented or implementation defined? It should be clearer than it is :-) The largest value wins. > * Does LD_CAP_FILES match the file names of shared objects, or their > SONAMEs, exact or substring match? The doc states: The most flexible means of defining LD_CAP_FILES is to use the base name of the required files. $ LD_HWCAP=-sse2 LD_CAP_FILES=libfoo.so,libbar.so ./main The files base name is the SONAME. The implementation actually uses the base name, full path name, or even alias names (symlinks) to match any LD_CAP_FILES requirements. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!