At runtime, the alternative shared object supplies one or more of the interfaces provided by the filter. This alternative shared object is referred to as a filtee. A filtee is built in the same manner as any shared object is built. Filtering provides a mechanism of abstracting the compilation environment from the runtime environment.
At link-edit time, a symbol reference that binds to a filter interface is resolved to the filters symbol definition. At runtime, a symbol reference that binds to a filter interface can be redirected to an alternative shared object.
Alternatively, a shared object can define all of the interfaces the shared object offers as filters by using the link-editor's -F or -f flag. These techniques are typically used individually, but can also be combined within the same shared object.
This filtering requires only a symbol table entry for the interface being filtered. At runtime, the implementation of a filter symbol definition must be provided from a filtee. Interfaces are defined to act as standard filters by using the link-editor's mapfile keyword FILTER , or by using the link-editor's -F flag.
This mapfile keyword or flag, is qualified with the name of one or more filtees that must supply the symbol definition at runtime. A filtee that cannot be processed at runtime is skipped. A standard filter symbol that cannot be located within the filtee, also causes the filtee to be skipped. In both of these cases, the symbol definition provided by the filter is not used to satisfy this symbol lookup.
This filtering provides a similar mechanism to standard filtering, except the filter provides a fall back implementation corresponding to the auxiliary filter interfaces. At runtime, the implementation of the symbol definition can be provided from a filtee. This mapfile keyword or flag, is qualified with the name of one or more filtees that can supply the symbol definition at runtime.
An auxiliary filter symbol that cannot be located within the filtee, also causes the filtee to be skipped. In both of these cases, the symbol definition provided by the filter is used to satisfy this symbol lookup. To generate a standard filter, you first define a filtee on which the filtering is applied. The following example builds a filtee filtee. Standard filtering can be provided in one of two ways.
To declare all of the interfaces offered by a shared object to be filters, use the link-editor's -F flag. In the following example, the shared object filter. The link-editor can reference the standard filter filter. The link-editor uses information from the symbol table of the filter to satisfy any symbol resolution. However, at runtime, any reference to the symbols of the filter result in the additional loading of the filtee filtee.
The runtime linker uses the filtee to resolve any symbols defined by filter. If the filtee is not found, or a filter symbol is not found in the filtee, the filter is skipped for this symbol lookup.
For example, the following dynamic executable prog , references the symbols foo and bar , which are resolved during link-edit from the filter filter. The execution of prog results in foo and bar being obtained from the filtee filtee. At runtime, any reference to the symbol foo of the filter, results in the additional loading of the filtee filtee.
The runtime linker uses the filtee to resolve only the symbol foo defined by filter. Reference to the symbol bar always uses the symbol from filter. The execution of prog results in foo being obtained from the filtee filtee. In these examples, the filtee filtee.
The filtee is not available to satisfy symbol lookup from any other objects that might be loaded as a consequence of executing prog. Standard filters provide a convenient mechanism for defining a subset interface of an existing shared object. Standard filters provide for the creation of an interface group spanning a number of existing shared objects.
Standard filters also provide a means of redirecting an interface to its implementation. Several standard filters are used in the Oracle Solaris OS. This subset represents the ABI-conforming functions and data items that reside in the C library that must be imported by a conforming application. These interfaces provide an abstraction between the symbols referenced in a compilation environment from libc. Historically, both libnsl. By establishing libnsl. As libnsl. Because the code in a standard filter is never referenced at runtime, adding content to any functions defined as filters is redundant.
Any filter code might require relocation, which would result in an unnecessary overhead when processing the filter at runtime. Functions are best defined as empty routines, or directly from a mapfile.
When generating data symbols within a filter, always associate the data with a section. This association can be produced by defining the symbol within a relocatable object file.
This association can also be produced by defining the symbol within a mapfile together with a size declaration and no value declaration. The resulting data definition ensures that references from a dynamic executable are established correctly. Some of the more complex symbol resolutions carried out by the link-editor require knowledge of a symbol's attributes, including the symbol's size.
Therefore, you should generate the symbols in the filter so that their attributes match the attributes of the symbols in the filtee.
Maintaining attribute consistency ensures that the link-editing process analyzes the filter in a manner that is compatible with the symbol definitions used at runtime. See Symbol Resolution. The link-editor uses the ELF class of the first relocatable file that is processed to govern the class of object that is created. Use the link-editor's option to create a 64—bit filter solely from a mapfile.
To generate an auxiliary filter, you first define a filtee on which the filtering is applied. Auxiliary filtering can be provided in one of two ways. To declare all of the interfaces offered by a shared object to be auxiliary filters, use the link-editor's -f flag. The link-editor can reference the auxiliary filter filter. However, at runtime, any reference to the symbols of the filter result in a search for the filtee filtee. If this filtee is found, the runtime linker uses the filtee to resolve any symbols defined by filter.
If the filtee is not found, or a symbol from the filter is not found in the filtee, then the original symbol within the filter is used. However, bar is obtained from the filter filter. At runtime, any reference to the symbol foo of the filter, results in a search for the filtee filtee.
If the filtee is found, the filtee is loaded. The filtee is then used to resolve the symbol foo defined by filter. If the filtee is not found, symbol foo defined by filter. If the filtee filtee. Auxiliary filters provide a mechanism for defining an alternative interface of an existing shared object.
This mechanism is used in the Oracle Solaris OS to provide optimized functionality within hardware capability, and platform specific shared objects.
Because auxiliary filters are frequently employed to provide platform specific optimizations, this option can be useful in evaluating filtee use and their performance impact. Individual interfaces that define standard filters, together with individual interfaces that define auxiliary filters, can be defined within the same shared object. A shared object that defines all of its interfaces to be filters by using the -F , or -f option, is either a standard or auxiliary filter.
A shared object can define individual interfaces to act as filters, together with defining all the interfaces of the object to act as a filters. In this case, the individual filtering defined for an interface is processed first. When a filtee for an individual interface filter can not be established, the filtee defined for all the interfaces of the filter provides a fall back if appropriate.
For example, consider the filter filter. This filter defines that all interfaces act as auxiliary filters against the filtee filtee. An external reference to foo results in processing the filtee foo. If foo can not be found from foo. In this case, no fall back processing is performed because foo is defined to be a standard filter. An external reference to bar results in processing the filtee bar. If bar can not be found from bar.
In this case, fall back processing is performed because bar is defined to be an auxiliary filter. If bar can not be found from filtee. The runtime linker's processing of a filter defers loading a filtee until a filter symbol is referenced. This implementation accounts for differences in dependency reporting that can be produced by tools such as ldd 1. The link-editor's -z loadfltr option can be used when creating a filter to cause the immediate processing of its filtees at runtime.
A shared object can be used by multiple applications within the same system. The performance of a shared object affects the applications that use the shared object, and the system as a whole. Although the code within a shared object directly affects the performance of a running process, the performance issues discussed here relate to the runtime processing of the shared object. The following sections investigate this processing in more detail by looking at aspects such as text size and purity, together with relocation overhead.
Various tools are available to analyze the contents of an ELF file, including the standard Unix utilities dump 1 , nm 1 , and size 1. Under Oracle Solaris, these tools have been largely superseded by elfdump 1. The ELF format organizes data into sections. Sections are in turn allocated to units known as segments. Some segments describe how portions of a file are mapped into memory. See mmapobj 2. These loadable segments can be displayed by using the elfdump 1 command and examining the LOAD entries.
There are two loadable segments in the shared object libfoo. This difference accounts for the. Programmers usually think of a file in terms of the symbols that define the functions and data elements within their code. These symbols can be displayed using the -s option to elfdump. The symbol table information displayed by elfdump includes the section the symbol is associated with. The elfdump -c option can be used to display information about these sections.
These sections, because of their read-only nature, are part of the text segment. Similarly, the data arrays data , and bss are associated with the sections. These sections, because of their writable nature, are part of the data segment. When an application is built using a shared object, the entire loadable contents of the object are mapped into the virtual address space of that process at runtime.
Each process that uses a shared object starts by referencing a single copy of the shared object in memory. Relocations within the shared object are processed to bind symbolic references to their appropriate definitions.
This results in the calculation of true virtual addresses that could not be derived at the time the shared object was generated by the link-editor.
These relocations usually result in updates to entries within the process's data segments. The memory management scheme underlying the dynamic linking of shared objects shares memory among processes at the granularity of a page. Memory pages can be shared as long as they are not modified at runtime. If a process writes to a page of a shared object when writing a data item, or relocating a reference to a shared object, it generates a private copy of that page. Connorhd 0.
See , See , , See 77 and Issue was initially raised up by olegkovalenko. NEWS: Version 2. Contributed by hjoukl gh issue , pr - Fixed recursive import issue with tz module gh pr - Added compatibility between tzwin objects and datetime. Version 2. Fractional values in absolute parameters year, day, etc are now deprecated.
This oversight has been corrected. Contributed by elprans gh pr - rrule now has an xafter method for retrieving multiple recurrences after a specified date. Contributed by Bachmann gh pr - Fixed parser issue where commas were not a valid separator between seconds and microseconds, preventing parsing of ISO dates. Contributed by ryanss gh issue 28 , pr - Fixed issue with tzwin encoding in locales with non-Latin alphabets gh issue 92 , pr 98 - Fixed an issue where tzwin was not being properly imported on Windows.
Contributed by labrys. Another aid might be to also use the link-editors -znocombreloc option. Having found a non-pic relocation, search back in the diagnostics and try and find the matching input relocation using the relocation type and symbol name.
The non-pic culprit is the file foo. You might be able to discover your non-pic relocations by just scanning through the "collecting input relocations" information. But for large links this can be a substantial amount of information to digest. The problem turned out to be in the libperl. After removing that object unresolved symbols starting showing. Recompiling globals with -m64 and -KPIC solved the problem. I have this problem - I get the "does not fit" error, and elfdump shows the TEXTREL object, but the linker debug output doesn't contain any "creating output relocations.
What relocation titles did you see in the output? Sections are all. That's all the debug output contains. Never mind. The sorry version of vi on my Solaris machine was truncating the debug file. It does in fact contain output relocations. Thanks for this post; I'm sure it will now help me nail down the issue. First, I'd try and identify what the text relocations reference.
For example, if I look at the first relocation:. Now if I look at what section this is I see:. So, it looks like a read-only data item const needs relocating. This can happen if you have a table of addresses, and the table is defined const. The studio compilers recognize this condition and normally place the table in a.
I see this object has a. I don't understand how I'm supposed to connect the offsets from the first set of data with what's in the second, to allow the suspect function to be identified. This is how pic code resolves a function all.
You want to looks at relocations against the. Relocation Section:. It's this relocation against the text section. It's hard to navigate that.
If you used the "-z nocombreloc" flag you wouldn't get a single. With these individual. With these individual sections it should be easier to look at the debug output and associate their creation back to the input files that produce them. Thank you. I found that '-z nocombreloc' was not supported on one of the SPARC systems I looked at - I got a message about an unrecognisded option. But '-z nocombreloc' is supported on the x64 system I'm using. Reply to author.
Report message as abuse. Show original message. Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message.
0コメント