+ addit = true;
+
+ /* In the PE format, section symbols actually refer to the
+ start of the output section. We handle them specially
+ here. */
+ if (obj_pe (abfd) && (flags & BSF_SECTION_SYM) != 0)
+ {
+ *sym_hash = coff_link_hash_lookup (coff_hash_table (info),
+ name, false, copy, false);
+ if (*sym_hash != NULL)
+ {
+ if (((*sym_hash)->coff_link_hash_flags
+ & COFF_LINK_HASH_PE_SECTION_SYMBOL) == 0
+ && (*sym_hash)->root.type != bfd_link_hash_undefined
+ && (*sym_hash)->root.type != bfd_link_hash_undefweak)
+ (*_bfd_error_handler)
+ ("Warning: symbol `%s' is both section and non-section",
+ name);
+
+ addit = false;
+ }
+ }
+
+ /* The Microsoft Visual C compiler does string pooling by
+ hashing the constants to an internal symbol name, and
+ relying on the the linker comdat support to discard
+ duplicate names. However, if one string is a literal and
+ one is a data initializer, one will end up in the .data
+ section and one will end up in the .rdata section. The
+ Microsoft linker will combine them into the .data
+ section, which seems to be wrong since it might cause the
+ literal to change.
+
+ As long as there are no external references to the
+ symbols, which there shouldn't be, we can treat the .data
+ and .rdata instances as separate symbols. The comdat
+ code in the linker will do the appropriate merging. Here
+ we avoid getting a multiple definition error for one of
+ these special symbols.
+
+ FIXME: I don't think this will work in the case where
+ there are two object files which use the constants as a
+ literal and two object files which use it as a data
+ initializer. One or the other of the second object files
+ is going to wind up with an inappropriate reference. */
+ if (obj_pe (abfd)
+ && (classification == COFF_SYMBOL_GLOBAL
+ || classification == COFF_SYMBOL_PE_SECTION)
+ && section->comdat != NULL
+ && strncmp (name, "??_", 3) == 0
+ && strcmp (name, section->comdat->name) == 0)
+ {
+ if (*sym_hash == NULL)
+ *sym_hash = coff_link_hash_lookup (coff_hash_table (info),
+ name, false, copy, false);
+ if (*sym_hash != NULL
+ && (*sym_hash)->root.type == bfd_link_hash_defined
+ && (*sym_hash)->root.u.def.section->comdat != NULL
+ && strcmp ((*sym_hash)->root.u.def.section->comdat->name,
+ section->comdat->name) == 0)
+ addit = false;
+ }
+
+ if (addit)
+ {
+ if (! (bfd_coff_link_add_one_symbol
+ (info, abfd, name, flags, section, value,
+ (const char *) NULL, copy, false,
+ (struct bfd_link_hash_entry **) sym_hash)))
+ goto error_return;
+ }
+
+ if (obj_pe (abfd) && (flags & BSF_SECTION_SYM) != 0)
+ (*sym_hash)->coff_link_hash_flags |=
+ COFF_LINK_HASH_PE_SECTION_SYMBOL;
+
+ /* Limit the alignment of a common symbol to the possible
+ alignment of a section. There is no point to permitting
+ a higher alignment for a common symbol: we can not
+ guarantee it, and it may cause us to allocate extra space
+ in the common section. */
projects / deliverable / binutils-gdb.git / blobdiff