This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
stripping debug info & local symbols
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: binutils <binutils at sources dot redhat dot com>
- Date: Tue, 03 Jun 2008 14:20:53 +0100
- Subject: 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