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] |
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
Attachment:
rel-rela-mainline.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |