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!
