Weird relocations

Weird relocations

[Toshi Morita]

I'm still examining the problem whereby an ELF executable is generated with
an invalid AT_low_pc, and I think I'm getting further on the problem.

Basically, It looks like the linker is applying the relocation against a 
nonexistent section possibly due to an assembler bug generating a bad
object file.

When this code in bfd/elf32-sh.c is executed:

      r_symndx = ELF32_R_SYM (rel->r_info);
...
      if (r_symndx < symtab_hdr->sh_info)
        {
          /* There is nothing to be done for an internal IND12W
             relocation.  FIXME: This is probably wrong, but it's how
             the COFF relocations work.  */
          if (r_type == (int) R_SH_IND12W)
            continue;
          sym = local_syms + r_symndx;
          sec = local_sections[r_symndx];
          relocation = (sec->output_section->vma
                        + sec->output_offset
                        + sym->st_value);
        }

the pointer "sec" is assigned a null value because r_symndex seems
to be invalid (when run in the debugger).

When I go dump out the relocations of that object file with sh-elf-objdump
--reloc, I see some suspicious relocations:

RELOCATION RECORDS FOR [.debug]:
OFFSET   TYPE              VALUE
00000008 R_SH_DIR32        .debug
00000053 R_SH_DIR32        .text
00000059 R_SH_DIR32        .text
0000005f R_SH_DIR32        .line
0000007c R_SH_DIR32        .debug_sfnames
00000082 R_SH_DIR32        .debug_srcinfo
0000008e R_SH_DIR32        .debug
000000b4 R_SH_DIR32        .debug
000000d9 R_SH_DIR32        .debug
...
0000b516 R_SH_DIR32        .debug
0000b51c R_SH_DIR32        .debug
0000b522 R_SH_DIR32        _bSqrt__Ff		<- here
0000b528 R_SH_DIR32        .L_f301_e		<- here
0000b52e R_SH_DIR32        .L_b301		<- here
0000b534 R_SH_DIR32        .L_b301_e		<- here

These relocations seems suspicious because all the other entries in the "VALUE"
field are names of sections, but these three are label names... and they are
also the relocations which are not properly applied.

Am I correct in assuming the "VALUE" field of a .debug relocation should
always contain a reference to a section, and not a label? And if so,
are these relocations clearly incorrect?

Toshi

Re: Weird relocations

[Ian Lance Taylor]

   From: Toshi Morita <tm2@best.com>
   Date: Fri, 24 Sep 1999 16:16:36 -0700 (PDT)

   When this code in bfd/elf32-sh.c is executed:

	 r_symndx = ELF32_R_SYM (rel->r_info);
   ...
	 if (r_symndx < symtab_hdr->sh_info)
	   {
	     /* There is nothing to be done for an internal IND12W
		relocation.  FIXME: This is probably wrong, but it's how
		the COFF relocations work.  */
	     if (r_type == (int) R_SH_IND12W)
	       continue;
	     sym = local_syms + r_symndx;
	     sec = local_sections[r_symndx];
	     relocation = (sec->output_section->vma
			   + sec->output_offset
			   + sym->st_value);
	   }

   the pointer "sec" is assigned a null value because r_symndex seems
   to be invalid (when run in the debugger).

This is specifically testing for the case of a local symbol.  r_symndx
may have been invalid, but it's not invalid for it to be larger than
symtab_hdr->sh_info; that just means the relocation is not against a
local symbol.

   When I go dump out the relocations of that object file with sh-elf-objdump
   --reloc, I see some suspicious relocations:

   RELOCATION RECORDS FOR [.debug]:
   OFFSET   TYPE              VALUE
   00000008 R_SH_DIR32        .debug
   00000053 R_SH_DIR32        .text
   00000059 R_SH_DIR32        .text
   0000005f R_SH_DIR32        .line
   0000007c R_SH_DIR32        .debug_sfnames
   00000082 R_SH_DIR32        .debug_srcinfo
   0000008e R_SH_DIR32        .debug
   000000b4 R_SH_DIR32        .debug
   000000d9 R_SH_DIR32        .debug
   ...
   0000b516 R_SH_DIR32        .debug
   0000b51c R_SH_DIR32        .debug
   0000b522 R_SH_DIR32        _bSqrt__Ff		<- here
   0000b528 R_SH_DIR32        .L_f301_e		<- here
   0000b52e R_SH_DIR32        .L_b301		<- here
   0000b534 R_SH_DIR32        .L_b301_e		<- here

   These relocations seems suspicious because all the other entries in the "VALUE"
   field are names of sections, but these three are label names... and they are
   also the relocations which are not properly applied.

   Am I correct in assuming the "VALUE" field of a .debug relocation should
   always contain a reference to a section, and not a label? And if so,
   are these relocations clearly incorrect?

It's OK for a .debug relocation to refer to a symbol, and I would
expect it in cases involving a global symbol.

I don't know why you are seeing relocations against symbols named .L*.
I wonder whether you have this patch in your sources:

1999-06-13  Ian Lance Taylor  <ian@zembu.com>

	* write.c (adjust_reloc_syms): Rather than never reducing reloc
	which refer to symbols in linkonce sections, permit reducing the
	relocs if the symbol is local.

As you can see, this again leads me to think about linkonce sections.
In what section are those symbols actually defined?

Ian

Re: Weird relocations

[Ian Lance Taylor]

   From: Toshi Morita <tm2@best.com>
   Date: Sat, 2 Oct 1999 22:49:09 -0700 (PDT)

   I'm seeing DWARF1 debug info in a final executable where the DW_high_pc
   is lower than the DW_low_pc, and it looks like the DW_low_pc isn't properly
   resolved; e.g. it has a value like 0000008 or 00000010.

   Okay, Ian Lance Taylor replied:

   > I don't know why you are seeing relocations against symbols named .L*.
   > I wonder whether you have this patch in your sources:
   > 
   > 1999-06-13  Ian Lance Taylor  <ian@zembu.com>
   > 
   >         * write.c (adjust_reloc_syms): Rather than never reducing reloc
   >         which refer to symbols in linkonce sections, permit reducing the
   >         relocs if the symbol is local.
   >
   >As you can see, this again leads me to think about linkonce sections.
   >In what section are those symbols actually defined?

   Yup, I checked a few of the symbols and they do seem to be in .gnu.linkonce
   sections...can any meaningful inferences be made from this?

Just that we have to either patch the linker to do something different
with these relocations, or we have to patch the debugger to handle
this case.  Patching the debugger is probably easier; it should
presumably just ignore debugging information like this.  Patching the
linker would unfortunately have to be done in a number of locations.

Ian

Re: Weird relocations

[Toshi Morita]

Quick recap:

I'm seeing DWARF1 debug info in a final executable where the DW_high_pc
is lower than the DW_low_pc, and it looks like the DW_low_pc isn't properly
resolved; e.g. it has a value like 0000008 or 00000010.

Okay, Ian Lance Taylor replied:

> I don't know why you are seeing relocations against symbols named .L*.
> I wonder whether you have this patch in your sources:
> 
> 1999-06-13  Ian Lance Taylor  <ian@zembu.com>
> 
>         * write.c (adjust_reloc_syms): Rather than never reducing reloc
>         which refer to symbols in linkonce sections, permit reducing the
>         relocs if the symbol is local.
>
>As you can see, this again leads me to think about linkonce sections.
>In what section are those symbols actually defined?

Yup, I checked a few of the symbols and they do seem to be in .gnu.linkonce
sections...can any meaningful inferences be made from this?

Toshi