More rel/rela fixes for ld -r

Bernd Schmidt bernds@codesourcery.com
Tue Sep 28 12:29:00 GMT 2010


On C6x, the TI compiler produces both rel and rela sections for the same
input section.  This causes confusion in the linker when trying to use
"ld -r".  In particular, the rel_hash information is inconsistent with
the relocations.

In elf_link_input_bfd, we compute the rel_hash information, creating one
block of such information for every input section (rel_count and
rel_count2 are updated in the process):
  rel_hash = (elf_section_data (o->output_section)->rel_hashes
              + elf_section_data (o->output_section)->rel_count
              + elf_section_data (o->output_section)->rel_count2);

This block contains information for both the REL and the RELA relocs.
However, when we later examine the data in rel_hash for the output
section, we expect there to be one large block containing the data
corresponding to the output section's rel_hdr, followed by another large
block corresponding to its rel_hdr2.  In other words, the data
corresponding to one input section is expected to be split up into two
blocks, one corresponding to rel_hdr and one corresponding to rel_hdr2
(rel_count now contains the final value):
      elf_link_adjust_relocs (abfd, &elf_section_data (o)->rel_hdr,
			      elf_section_data (o)->rel_count,
			      elf_section_data (o)->rel_hashes);
      if (elf_section_data (o)->rel_hdr2 != NULL)
	elf_link_adjust_relocs (abfd, elf_section_data (o)->rel_hdr2,
				elf_section_data (o)->rel_count2,
				(elf_section_data (o)->rel_hashes
				 + elf_section_data (o)->rel_count));

All this is complicated by the fact that different input files need not
have rel and rela sections in the same order, or even that all input
files must have both - it is possible for some inputs to have only one
of the sections.  All this can cause us to become confused about which
relocs go where.

The draft patch below attempts to fix this by removing the
rel_hdr/rel_hdr2 scheme, and providing a new bfd_elf_section_reloc_data
structure which holds information about one set of relocs.  There are
two of these in bfd_elf_section_data, one for rel and one for rela, and
there is one rel_hash array allocated for each.  When both are present,
all code assumes that data for rel comes before data for rela.

Before I go and have a go at converting all the backend code that's
probably broken by this - does this look like an acceptable approach?
Should I remove the code in elf32_{tic6x,m32r}_fake_section and make the
linker automatically create the necessary sections in the output?

What kind of testing is required for a patch like this?


Bernd

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rel-rela-mainline.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20100928/812a112b/attachment.ksh>


More information about the Binutils mailing list