This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gold assert after "relocation refers to discarded section" warnings


>> Actually, though, why is there no GOT offset assigned? ?The code which
>> sets the GOT offset is independent of the code which notices that the
>> symbol is defined in a discarded section. ?It seems like we should still
>> see the GOT reloc against the symbol.
>
> You're right, there should be one. I need to dig deeper...

I spoke too soon. For relocations against local symbols, we ignore the
relocation if the section is discarded:

	  if (is_ordinary
	      && shndx != elfcpp::SHN_UNDEF
	      && !object->is_section_included(shndx)
              && !symtab->is_section_folded(object, shndx))
	    {
	      // RELOC is a relocation against a local symbol in a
	      // section we are discarding.  We can ignore this
	      // relocation.  It will eventually become a reloc
	      // against the value zero.
	      //
	      // FIXME: We should issue a warning if this is an
	      // allocated section; is this the best place to do it?
	      //
	      // FIXME: The old GNU linker would in some cases look
	      // for the linkonce section which caused this section to
	      // be discarded, and, if the other section was the same
	      // size, change the reloc to refer to the other section.
	      // That seems risky and weird to me, and I don't know of
	      // any case where it is actually required.

	      continue;
	    }
	  scan.local(symtab, layout, target, object, data_shndx,
		     output_section, reloc, r_type, lsym);

In the case of a local symbol belonging (incorrectly) to a
non-allocated section like .symtab.shndx, we will always skip the
relocation during the scan phase, and thus no GOT entry will be
allocated.

I'm thinking for the case where the relocation refers to a non-BITS
section, we should print a fatal message here; it means the file is
corrupt and there's no point in completing the link. (We could make it
an error instead, to diagnose all the problems instead of just the
first, as we shouldn't get into trouble until the second pass.)

For relocations to local symbols that really are in discarded COMDAT
sections, I think we do need to relax the assert in
Relocate::relocate().

BTW, the first FIXME above is probably dead -- we now warn later in
relocate_section(). And the second FIXME is also taken care of there
with Sized_relobj_file::map_to_kept_section(). OK with you if I remove
those FIXMEs?

-cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]