files.c revision f441771b0ce9f9d6122d318ff8290cb1a2848f9d
* Check sanity of file header and allocate an infile descriptor * for the file being processed. * Is this file using 'extended Section Indexes'. If so, use the * e_shnum & e_shstrndx which can be found at: * e_shnum == Shdr[0].sh_size * e_shstrndx == Shdr[0].sh_link * Record this new input file on the shared object or relocatable * object input file list. * Process a generic section. The appropriate section information is added * to the files input descriptor list. * Create a new input section descriptor. If this is a NOBITS * section elf_getdata() will still create a data buffer (the buffer * will be null and the size will reflect the actual memory size). * Add the new input section to the files input section list and * flag whether the section needs placing in an output section. This * placement is deferred until all input section processing has been * completed, as SHT_GROUP sections can provide information that will * affect how other sections within the file should be placed. * Determine the software capabilities of the object being built from the * capabilities of the input relocatable objects. One software capability * is presently recognized, and represented with the following (sys/elf.h): * SF1_SUNW_FPKNWN use/non-use of frame pointer is known, and * SF1_SUNW_FPUSED the frame pointer is in use. * The resolution of the present fame pointer state, and the capabilities * provided by a new input relocatable object are: * new input relocatable object * present | SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN | <unknown> * state | SF1_SUNW_FPUSED | | * --------------------------------------------------------------------------- * SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN * SF1_SUNW_FPUSED | SF1_SUNW_FPUSED | | SF1_SUNW_FPUSED * --------------------------------------------------------------------------- * SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN * --------------------------------------------------------------------------- * <unknown> | SF1_SUNW_FPKNWN | SF1_SUNW_FPKNWN | <unknown> * If a mapfile has established definitions to override any object * capabilities, ignore any new object capabilities. * The SF1_SUNW_ADDR32 is only meaningful when building a 64-bit * object. Warn the user, and remove the setting, if we're * building a 32-bit object. * If this object doesn't specify any capabilities, ignore it, and * Make sure we only accept known software capabilities. Note, that * an F1_SUNW_FPUSED by itself is viewed as bad practice. * If the input file is not a relocatable object, then we're only here * to warn the user of any questionable capabilities. * If we're building a 64-bit executable, and we come across a * dependency that requires a restricted address space, then * that dependencies requirement can only be satisfied if the * executable triggers the restricted address space. This is a * warning rather than a fatal error, as the possibility exists * that an appropriate dependency will be provided at runtime. * The runtime linker will refuse to use this dependency. * Determine the resolution of the present frame pointer and the * new input relocatable objects frame pointer. * If the new relocatable object isn't using a frame pointer, * reduce the present state to unused. * Having processed the frame pointer bits, remove them from * the value so they don't get OR'd in below. * If the present frame pointer state is unknown, mask it out * and allow the values from the new relocatable object /* Do not take the frame pointer flags from the object */ * Determine the hardware capabilities of the object being built from the * capabilities of the input relocatable objects. There's really little to * do here, other than to offer diagnostics, hardware capabilities are simply * If a mapfile has established definitions to override any object * capabilities, ignore any new object capabilities. * If this object doesn't specify any capabilities, ignore it, and * Promote a machine capability or platform capability to the output file. * Multiple instances of these names can be defined. * If a mapfile has established definitions to override this capability, * ignore any new capability. * Promote a capability identifier to the output file. A capability group can * only have one identifier, and thus only the first identifier seen from any * input relocatable objects is retained. An explicit user defined identifier, * rather than an an identifier fabricated by ld(1) with -z symbcap processing, * takes precedence. Note, a user may have defined an identifier via a mapfile, * in which case the mapfile identifier is retained. * Promote a capabilities group to the object capabilities. This catches a * corner case. An object capabilities file can be converted to symbol * capabilities with -z symbolcap. However, if the user has indicated that all * the symbols should be demoted, we'd be left with a symbol capabilities file, * with no associated symbols. Catch this case by promoting the symbol * capabilities back to object capabilities. * Determine whether a capabilities group already exists that describes this * new capabilities group. * Note, a capability group identifier, CA_SUNW_ID, isn't used as part of the * comparison. This attribute simply assigns a diagnostic name to the group, * and in the case of multiple identifiers, the first will be taken. * If the new capabilities contains a CA_SUNW_ID, drop the count of the * number of comparable items. * Traverse the existing symbols capabilities groups. * If a matching group is found, then this new group has * already been supplied by a previous file, and hence the * existing group can be used. Record this new input section, * from which we can also derive the input file name, on the * existing groups input sections. * If a capabilities group is not found, create a new one. * If we're converting object capabilities to symbol capabilities and * no CA_SUNW_ID is defined, fabricate one. This identifier is appended * to all symbol names that are converted into capabilities symbols, * Create an identifier using the group number together with a * default template. We allocate a buffer large enough for any * possible number of items (way more than we need). * Null the callers alist's as they've effectively been transferred * Keep track of which input section, and hence input file, established * Keep track of the number of symbol capabilities entries that will be * required in the output file. Each group requires a terminating * Capture symbol capability family information. This data structure is focal * in maintaining all symbol capability relationships, and provides for the * eventual creation of a capabilities information section, and possibly a * capabilities chain section. * Capabilities families are lead by a CAPINFO_SUNW_GLOB symbol. This symbol * provides the visible global symbol that is referenced by all external * callers. This symbol may have aliases. For example, a weak/global symbol * pair, such as memcpy()/_memcpy() may lead the same capabilities family. * Each family contains one or more local symbol members. These members provide * the capabilities specific functions, and are associated to a capabilities * group. For example, the capability members memcpy%sun4u and memcpy%sun4v * might be associated with the memcpy() capability family. * This routine is called when a relocatable object that provides object * capabilities is transformed into a symbol capabilities object, using the * This routine is also called to collect the SUNW_capinfo section information * of a relocatable object that contains symbol capability definitions. * Make sure the capability families have an initialized AVL tree. * When creating a dynamic object, capability family members * are maintained in a .SUNW_capchain, the first entry of * which is the version number of the chain. * Determine whether a family already exists, and if not, create one * using the lead family symbol. * When creating a dynamic object, capability family members * are maintained in a .SUNW_capchain, each family starts with * this lead symbol, and is terminated with a 0 element. * If no group information is provided then this request is to add a * lead capability symbol, or lead symbol alias. If this is the lead * symbol there's nothing more to do. Otherwise save the alias. * Determine whether a member of the same group as this new member is * already defined within this family. If so, we have a multiply * Diagnose that a multiple symbol definition exists. * Add this capabilities symbol member to the family. * When creating a dynamic object, capability family members are * maintained in a .SUNW_capchain. Account for this family member. * If this input file is undergoing object capabilities to symbol * capabilities conversion, then this member is a new local symbol * that has been generated from an original global symbol. Keep track * of this symbol so that the output file symbol table can be populated * with these new symbol entries. * Process a SHT_SUNW_cap capabilities section. * Determine the capabilities data and size. * Traverse the section to determine what capabilities groups are * A capabilities section can contain one or more, CA_SUNW_NULL * - The first group defines the object capabilities. * - Additional groups define symbol capabilities. * - Since the initial group is always reserved for object * capabilities, any object with symbol capabilities must also * have an object capabilities group. If the object has no object * capabilities, an empty object group is defined, consisting of a * CA_SUNW_NULL element in index [0]. * - If any capabilities require references to a named string, then * the section header sh_info points to the associated string * - If an object contains symbol capability groups, then the * section header sh_link points to the associated capinfo table. * If this is the first CA_SUNW_NULL entry, and no * capabilities group has been found, then this object * does not define any object capabilities. * If this is the start of a new group, save it. * If a string capabilities entry has been found, the capabilities * section must reference the associated string table. * The processing of capabilities groups is as follows: * - if a relocatable object provides only object capabilities, and * the -z symbolcap option is in effect, then the object * capabilities are transformed into symbol capabilities and the * symbol capabilities are carried over to the output file. * - in all other cases, any capabilities present in an input * relocatable object are carried from the input object to the * output without any transformation or conversion. * Capture any object capabilities that are to be carried over to the * Object capabilities end at the first null. * Only the object software capabilities that are * defined in a relocatable object become part of the * object software capabilities in the output file. * However, check the validity of any object software * capabilities of any dependencies. * The remaining capability types must come from a * relocatable object in order to contribute to the assert(0);
/* Unknown capability type */ * If there are no symbol capabilities, or this objects * capabilities aren't being transformed into a symbol * capabilities, then we're done. * If these capabilities don't originate from a relocatable object * there's no further processing required. * If this object only defines an object capabilities group, and the * -z symbolcap option is in effect, then all global function symbols * and initialized global data symbols are renamed and assigned to the * transformed symbol capabilities group. * Allocate a capabilities descriptor to collect the capabilities data * for this input file. Allocate a mirror of the raw capabilities data * that points to the individual symbol capabilities groups. An APlist * is used, although it will be sparsely populated, as the list provides * a convenient mechanism for traversal later. * Clear the allocated APlist data array, and assign the number of * items as the total number of array items. (
cnum *
sizeof (
void *)));
* Traverse the capabilities data, unpacking the data into a * capabilities set. Process each capabilities set as a unique group. * Process the capabilities group that this null entry * terminates. The capabilities group that is returned * will either point to this file's data, or to a * matching capabilities group that has already been * Note, if this object defines object capabilities, * the first group descriptor points to these object * capabilities. It is only necessary to save this * descriptor when object capabilities are being * transformed into symbol capabilities (-z symbolcap). * Clean up the capabilities data in preparation * for processing additional groups. If the * collected capabilities strings were used to * establish a new output group, they will have * been saved in get_cap_group(). If these * descriptors still exist, then an existing * descriptor has been used to associate with * this file, and these string descriptors can * Save the start of this new group. * Capture any symbol capabilities symbols. An object file that contains symbol * capabilities has an associated .SUNW_capinfo section. This section * identifies which symbols are associated to which capabilities, together with * their associated lead symbol. Each of these symbol pairs are recorded for * Catch any anomalies. A capabilities symbol should be valid, * and the capabilities lead symbol should also be global. * Note, ld(1) -z symbolcap would create local capabilities * symbols, but we don't enforce this so as to give the * compilation environment a little more freedom. * Indicate that this is a capabilities symbol. * Save any global capability symbols. Global capability * symbols are identified with a CAPINFO_SUNW_GLOB group id. * The lead symbol for this global capability symbol is either * the symbol itself, or an alias. * Track the number of non-global capabilities symbols, as these * are used to size any symbol tables. If we're generating a * dynamic object, this symbol will be added to the dynamic * symbol table, therefore ensure there is space in the dynamic * As we're tracking this local symbol as a capabilities symbol, * reduce the local symbol count to compensate. * Determine whether the associated lead symbol indicates * NODYNSORT. If so, remove this local entry from the * SUNW_dynsort section too. NODYNSORT tagging can only be * obtained from a mapfile symbol definition, and thus any * global definition that has this tagging has already been * instantiated and this instance resolved to it. * Track this family member, together with its associated group. * Simply process the section so that we have pointers to the data for use * in later routines, however don't add the section to the output section * list as we will be creating our own replacement sections later (ie. * symtab and relocation). * Keep a running count of relocation entries from input relocatable objects for * sizing relocation buckets later. If we're building an executable, save any * relocations from shared objects to determine if any copy relocation symbol * has a displacement relocation against it. * Process a string table section. A valid section contains an initial and * Never include .stab.excl sections in any output file. * If the -s flag has been specified strip any .stab sections. * If we got here to process a .shstrtab or .dynstr table, `ident' will * be null. Otherwise make sure we don't have a .strtab section as this * should not be added to the output section list either. * String tables should start and end with a NULL byte. Note, it has * been known for the assembler to create empty string tables, so check * the size before attempting to verify the data itself. * Invalid sections produce a warning and are skipped. * Compare an input section name to a given string, taking the ELF '%' * section naming convention into account. If an input section name * contains a '%' character, the '%' and all following characters are * ignored in the comparison. * is_name - Name of input section * match_name - Name to compare to * match_len - strlen(match_name) * Returns True (1) if the names match, and False (0) otherwise. * If the start of is_name is not a match for name, * The prefix matched. The next character must be either '%', or * NULL, in order for a match to be true. * Helper routine for process_progbits() to process allocable sections. * name, ifl, shdr, ndx, ident, ofl - As passed to process_progbits(). * is_stab_index - TRUE if section is .index. * is_flags - Additional flags to be added to the input section. * The allocable section has been processed. *ident and *is_flags * are updated as necessary to reflect the changes. Returns TRUE * for success, FALSE for failure. * Only accept a progbits .eh_frame on a platform * for which this is the expected type. * This is a work-around for x86 compilers that have * set SHF_ALLOC for the .stab.index section. * Because of this, make sure that the .stab.index * does not end up as the last section in the text * segment. Older linkers can produce segmentation * violations when they strip (ld -s) against a * shared object whose last section in the text * Process a progbits section. * Never include .stab.excl sections in any output file. * If the -s flag has been specified strip any .stab sections. * Update the ident to reflect the type of section we've got. * If there is any .plt or .got section to generate we'll be creating * our own version, so don't allow any input sections of these types to * be added to the output section list (why a relocatable object would * have a .plt or .got is a mystery, but stranger things have occurred). * If there are any unwind sections, and this is a platform that uses * SHT_PROGBITS for unwind sections, then set their ident to reflect * On success, process_section() creates an input section descriptor. * Now that it exists, we can add any pending input section flags. * Handles the SHT_SUNW_{DEBUG,DEBUGSTR) sections. * Debug information is discarded when the 'ld -s' flag is invoked. * Process a nobits section. * Process a SHT_*_ARRAY section. * Process a SHT_SYMTAB_SHNDX section. * Have we already seen the related SYMTAB - if so verify it now. * Final processing for SHT_SYMTAB_SHNDX section. * Process .dynamic section from a relocatable object. * Note: That the .dynamic section is only considered interesting when * dlopen()ing a relocatable object (thus FLG_OF1_RELDYN can only get * set when libld is called from ld.so.1). * Process .dynamic sections from relocatable objects ? * Find the string section associated with the .dynamic section. * And get the .dynamic data * The Solaris ld does not put DT_VERSYM in the * dynamic section. If the object has DT_VERSYM, * then it must have been produced by the GNU ld, * and is using the GNU style of versioning. * Expand implicit references. Dependencies can be specified in terms of the * $ORIGIN, $MACHINE, $PLATFORM, $OSREL and $OSNAME tokens, either from their * needed name, or via a runpath. In addition runpaths may also specify the * Probably the most common reference to explicit dependencies (via -L) will be * sufficient to find any associated implicit dependencies, but just in case we * expand any occurrence of these known tokens here. * Note, if any errors occur we simply return the original name. * For $ORIGIN, expansion is really just a concatenation * of the parents directory name. For example, an * Establish the machine from sysconf - like uname -i. * Establish the platform from sysconf - like uname -i. * Establish the os name - like uname -s. * Establish the os release - like uname -r. * Establish instruction sets from sysconf. Note that * this is only meaningful from runpaths. * As ISALIST expands to a number of elements, * establish a new list to return to the caller. * This will contain the present path being * processed redefined for each isalist option, * plus the original remaining list entries. * If no expansion occurred skip the $ and continue. * If any ISALIST processing has occurred not only do we return the * expanded node we're presently working on, but we must also update the * remaining list so that it is effectively prepended with this node * expanded to all remaining isalist options. Note that we can only * handle one ISALIST per node. For more than one ISALIST to be * processed we'd need a better algorithm than above to replace the * newly generated list. Whether we want to encourage the number of * pathname permutations this would provide is another question. So, for * now if more than one ISALIST is encountered we return the original * The Solaris ld does not put DT_VERSYM in the dynamic section, but the * GNU ld does, and it is used by the runtime linker to implement their * versioning scheme. Use this fact to determine if the sharable object * was produced by the GNU ld rather than the Solaris one, and to set * FLG_IF_GNUVER if so. This needs to be done before the symbols are * processed, since the answer determines whether we interpret the * symbols versions according to Solaris or GNU rules. /* Get the .dynamic data */ * Process a dynamic section. If we are processing an explicit shared object * then we need to determine if it has a recorded SONAME, if so, this name will * be recorded in the output file being generated as the NEEDED entry rather * than the shared objects filename itself. * If the mode of the link-edit indicates that no undefined symbols should * remain, then we also need to build up a list of any additional shared object * dependencies this object may have. In this case save any NEEDED entries * together with any associated run-path specifications. This information is * recorded on the `ofl_soneed' list and will be analyzed after all explicit * file processing has been completed (refer finish_libs()). * First loop through the dynamic section looking for a run path. * Now look for any needed dependencies (which may use the rpath) * Update the input file structure with this new name. * Determine if this needed entry is already recorded on * the shared object needed list, if not create a new * definition for later processing (see finish_libs()). * Record the runpath (Note that we take the first * runpath which is exactly what ld.so.1 would do during * its dependency processing). * Record audit string as DT_DEPAUDIT. * If this dependency has the DT_SUNW_RTLDINF .dynamic * entry, then ensure no specialized dependency * processing is in effect. This tag identifies libc, * which provides critical startup information (TLS * routines, threads initialization, etc.) that must * be exercised as part of process initialization. * Perform some SONAME sanity checks. * Determine if anyone else will cause the same SONAME to be * used (this is either caused by two different files having the * same SONAME, or by one file SONAME actually matching another * file basename (if no SONAME is specified within a shared * library its basename will be used)). Probably rare, but some * Determine the basename of each file. Perhaps * there are multiple copies of the same file * being brought in using different -L search * paths, and if so give an extra hint in the * If the SONAME is the same as the name the user wishes to * record when building a dynamic library (refer -h option), * we also have a name clash. * Process a progbits section from a relocatable object (ET_REL). * This is used on non-amd64 objects to recognize .eh_frame sections. * Process a group section. * Indicate that this input file has groups to process. Groups are * processed after all input sections have been processed. * Process a relocation entry. At this point all input sections from this * input file have been assigned an input section descriptor which is saved * in the `ifl_isdesc' array. * Make sure this is a valid relocation we can handle. * From the relocation section header information determine which * section needs the actual relocation. Determine which output section * this input section has been assigned to and add to its relocation * list. Note that the relocation section may be null if it is not * required (ie. .debug, .stabs, etc). * Discard relocations if they are against a section * which has been discarded. * This section is processed later in * SHF_EXCLUDE flags is set for this section. * Sections SHT_SYMTAB and SHT_DYNDYM, even if SHF_EXCLUDE is on, might * be needed for ld processing. These sections need to be in the * internal table. Later it will be determined whether they can be * A conflict, issue an warning message, and ignore the section. * This sections is not going to the output file. * Section processing state table. `Initial' describes the required initial * procedure to be called (if any), `Final' describes the final processing * procedure (ie. things that can only be done when all required sections * Process an elf file. Each section is compared against the section state * table to determine whether it should be processed (saved), ignored, or * is invalid for the type of input file being processed. * Path information buffer used by ld_place_section() and related * routines. This information is used to evaluate entrance criteria * with non-empty file matching lists (ec_files). * First process the .shstrtab section so that later sections can * Reset the name since the shdr->sh_name could have been changed as * part of ld_sup_input_section(). * Determine the state table column from the input file type. Note, * shared library sections are not added to the output section list. * As we've already processed the .shstrtab don't do it again. * Reset the name since the shdr->sh_name could have been * changed as part of ld_sup_input_section(). * If the section has the SHF_EXCLUDE flag on, and we're not * generating a relocatable object, exclude the section. * If this is a standard section type process it via the * appropriate action routine. * If this section is below SHT_LOSUNW then we don't * really know what to do with it, issue a warning * message but do the basic section processing anyway. * Handle sections greater than SHT_LOSUNW. * SHT_SPARC_GOTDATA (0x70000000) is in the * SHT_LOPROC - SHT_HIPROC range reserved * for processor-specific semantics. It is * only meaningful for sparc targets. * SHT_AMD64_UNWIND (0x70000001) is in the * SHT_LOPROC - SHT_HIPROC range reserved * for processor-specific semantics. It is * only meaningful for amd64 targets. * Target is x86, so this really is * Now that all input sections have been analyzed, and prior to placing * any input sections to their output sections, process any groups. * Groups can contribute COMDAT items, which may get discarded as part * of placement. In addition, COMDAT names may require transformation * to indicate different output section placement. * Now that all of the input sections have been processed, place * them in the appropriate output sections. * Place all non-ordered sections within their appropriate * Count the number of ordered sections and retain the first * ordered section index. This will be used to optimize the * ordered section loop that immediately follows this one. * Having placed all the non-ordered sections, it is now /* ld_process_ordered() calls ld_place_section() */ /* If we've done them all, stop searching */ * If this is a shared object explicitly specified on the command * line (as opposed to being a dependency of such an object), * determine if the user has specified a control definition. This * descriptor may specify which version definitions can be used * from this object. It may also update the dependency to USED and * supply an alternative SONAME. * Use the basename of the input file (typically this is the * compilation environment name, ie. libfoo.so). * Before symbol processing, process any capabilities. Capabilities * can reference a string table, which is why this processing is * carried out after the initial section processing. Capabilities, * together with -z symbolcap, can require the conversion of global * symbols to local symbols. * Process any version dependencies. These will establish shared object * `needed' entries in the same manner as will be generated from the * .dynamic's NEEDED entries. * Before processing any symbol resolution or relocations process any * Having collected the appropriate sections carry out any additional * processing if necessary. * If this is a SHT_SUNW_move section from a relocatable file, * keep track of the section for later processing. * If this is a standard section type process it via the * appropriate action routine. * SHT_AMD64_UNWIND (0x70000001) is in the SHT_LOPROC - * SHT_HIPROC range reserved for processor-specific * semantics, and is only meaningful for amd64 targets. * Only process unwind contents from relocatable * Following symbol processing, if this relocatable object input file * provides symbol capabilities, tag the associated symbols so that * the symbols can be re-assigned to the new capabilities symbol * section that will be created for the output file. * After processing any symbol resolution, and if this dependency * indicates it contains symbols that can't be directly bound to, * set the symbols appropriately. * Process the current input file. There are basically three types of files * that come through here: * - files explicitly defined on the command line (ie. foo.o or bar.so), * in this case only the `name' field is valid. * - libraries determined from the -l command line option (ie. -lbar), * in this case the `soname' field contains the basename of the located * Any shared object specified via the above two conventions must be recorded * as a needed dependency. * - libraries specified as dependencies of those libraries already obtained * via the command line (ie. bar.so has a DT_NEEDED entry of fred.so.1), * in this case the `soname' field contains either a full pathname (if the * needed entry contained a `/'), or the basename of the located file. * These libraries are processed to verify symbol binding but are not * recorded as dependencies of the output file being generated. * soname - SONAME for needed sharable library, as described above * fd - Open file descriptor * flags - FLG_IF_ flags applicable to file * ofl - Output file descriptor * rej - Rejection descriptor used to record rejection reason * ifl_ret - NULL, or address of pointer to receive reference to * resulting input descriptor for file. If ifl_ret is non-NULL, * the file cannot be an archive or it will be rejected. * If a error occurs in examining the file, S_ERROR is returned. * If the file can be examined, but is not suitable, *rej is updated, * and 0 is returned. If the file is acceptable, 1 is returned, and if * ifl_ret is non-NULL, *ifl_ret is set to contain the pointer to the * resulting input descriptor. * If this file was not extracted from an archive obtain its device * information. This will be used to determine if the file has already * been processed (rather than simply comparing filenames, the device * information provides a quicker comparison and detects linked files). * If the caller has supplied a non-NULL ifl_ret, then * we cannot process archives, for there will be no * input file descriptor for us to return. In this case, * Determine if we've already come across this archive file. * We've seen this file before so reuse the * original archive descriptor and discard the * new elf descriptor. Note that a file * descriptor is unnecessary, as the file is * already available in memory. * As we haven't processed this file before establish a new * Indicate that the ELF descriptor no longer requires a file * descriptor by reading the entire file. The file is already * read via the initial mmap(2) behind elf_begin(3elf), thus * this operation is effectively a no-op. However, a side- * effect is that the internal file descriptor, maintained in * the ELF descriptor, is set to -1. This setting will not * be compared with any file descriptor that is passed to * elf_begin(), should this archive, or one of the archive * members, be processed again from the command line or * because of a -z rescan. * Obtain the elf header so that we can determine what type of * elf ELF_K_ELF file this is. * This can fail for a number of reasons. Typically * the object class is incorrect (ie. user is building * 64-bit but managed to point at 32-bit libraries). * Other ELF errors can include a truncated or corrupt * file. Try to get the best error message possible. * Determine if we've already come across this file. * Traverse the appropriate file list and determine if * Ifl_desc generated via -Nneed, therefore no * Disregard (skip) this image. * If the file was explicitly defined on the * command line (this is always the case for * relocatable objects, and is true for shared * objects when they weren't specified via -l or * were dragged in as an implicit dependency), * Determine whether this is the same * file name as originally encountered * so as to provide the most * descriptive diagnostic. * At this point, we know we need the file. Establish an input * file descriptor and continue processing. * If -zignore is in effect, mark this file as a potential * candidate (the files use isn't actually determined until * symbol resolution and relocation processing are completed). * Record any additional shared object information. * If no soname is specified (eg. this file was * derived from a explicit filename declaration on the * command line, ie. bar.so) use the pathname. * This entry may be overridden if the files dynamic * section specifies an DT_SONAME value. * If direct bindings, lazy loading, group permissions, * or deferred dependencies need to be established, mark * Determine whether this dependency requires a syminfo. * Having successfully opened a file, set up the necessary elf structures to * process it further. This small section of processing is slightly different * from the elf initialization required to process a relocatable object from an * archive (see libs.c: ld_process_archive()). * Determine whether the support library wishes to process this open. * The support library may return: * . a different ELF descriptor (in which case they should have * . a different file descriptor (in which case they should have * . a different path and file name (presumably associated with * a different file descriptor) * A file descriptor of -1, or and ELF descriptor of zero indicates * the file should be ignored. * Having successfully mapped a file, set up the necessary elf structures to * process it further. This routine is patterned after ld_process_open() and * is only called by ld.so.1(1) to process a relocatable object. * Process a required library (i.e. the dependency of a shared object). * Combine the directory and filename, check the resultant path size, and try * Determine the sizes of the directory and filename to insure we don't * Build the entire pathname and try and open the file. * Finish any library processing. Walk the list of so's that have been listed * as "included" by shared objects we have previously processed. Examine them, * without adding them as explicit dependents of this program, in order to * complete our symbol definition process. The search path rules are: * - use any user supplied paths, i.e. LD_LIBRARY_PATH and -L, then * - use any RPATH defined within the parent shared object, then * - use the default directories, i.e. LIBPATH or -YP. * Make sure we are back in dynamic mode. * See if this file has already been processed. At the time * this implicit dependency was determined there may still have * been more explicit dependencies to process. Note, if we ever * do parse the command line three times we would be able to * do all this checking when processing the dynamic section. * If the current path name element embeds a "/", then it's to * be taken "as is", with no searching involved. Process all * "/" occurrences, so that we can deduce the base file name. * Now search for this file in any user defined directories. * Next use the local rules defined within the parent shared * Finally try the default library search directories. * If we've got this far we haven't found the shared object. * If an object was found, but was rejected for some reason, * print a diagnostic to that effect, otherwise generate a * generic "not found" diagnostic. * Finally, now that all objects have been input, make sure any version * requirements have been met.