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]

stripping debug info & local symbols


I'm trying to fix a bug where objcopy -g is breaking relocations in a relocatable vxworks executable. The executable is generated by a non-gnu linker. It contains the following reloc and symbol table entry:

0000003e 00001206 R_PPC_ADDR16_HA 00000020 .text + 30

18: 00000020 0 SECTION LOCAL DEFAULT 1

the symbol is 0x20 bytes into the .text section. The reloc's addend is 0x30, so after relocation we should get an 0x50 addend. However, upon stripping the debug information, we end up with the following reloc and its symbol:

0000003e 00000206 R_PPC_ADDR16_HA 00000000 .text + 30

2: 00000000 0 SECTION LOCAL DEFAULT 1

Notice the symbol is now zero bytes into the .text section, so our relocations don't work out any longer.

I've traced the problem to the following fragment in elf.c:

  /* When gas creates relocations against local labels, it creates its
     own symbol for the section, but does put the symbol into the
     symbol chain, so udata is 0.  When the linker is generating
     relocatable output, this section symbol may be for one of the
     input sections rather than the output section.  */
  if (asym_ptr->udata.i == 0
      && (flags & BSF_SECTION_SYM)
      && asym_ptr->section)
    {
      asection *sec;
      int indx;

      sec = asym_ptr->section;
      if (sec->owner != abfd && sec->output_section != NULL)
	sec = sec->output_section;
      if (sec->owner == abfd
	  && (indx = sec->index) < elf_num_section_syms (abfd)
	  && elf_section_syms (abfd)[indx] != NULL)
	asym_ptr->udata.i = elf_section_syms (abfd)[indx]->udata.i;
    }

which is being used to write out the .text relocs.

At this point asym_ptr is the original +0x20 symbol, abfd is the output bfd and sec->owner is the input bfd and asym_ptr->udata.i is zero. We end up with the output section's .text section symbol and lose the 0x20 offset.

objcopy has correctly determine the +0x20 input symbol needs to be in the output symbol table. How udata.i is being used here is not clear to me. Should something have set it earlier? Should sec->output_offset be checked in some way? Any clues?

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery


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