mn10300 relaxation vs got

mn10300 relaxation vs got

[DJ Delorie]

In bfd/elf-m10300.c's mn10300_elf_relax_section(), we have this code:

      /* Try to turn a 32bit immediate, displacement or absolute address
	 into a 16bit immediate, displacement or absolute address.  */
      if (ELF32_R_TYPE (irel->r_info) == (int) R_MN10300_32
	  || ELF32_R_TYPE (irel->r_info) == (int) R_MN10300_GOT32
	  || ELF32_R_TYPE (irel->r_info) == (int) R_MN10300_GOTOFF32
	  || ELF32_R_TYPE (irel->r_info) == (int) R_MN10300_GOTPC32)

However, GOTPC32 is not an immediate, displacement, or absolute
address.  It's a pc-relative special case.  The attached sample code
demonstrates a problem with this: relaxing can move the opcode too far
away for the relaxed value to fit (the values are carefully chosen so
that the GOT relax must happen before the others).

Why is GOTPC32 included in this part of the code?  As a cross-section
pcrel reloc, it seems to me that it would be difficult to properly
relax these, except perhaps as a single pass after everything else, so
we know these opcodes won't move any more after they've been relaxed.
Ideas?  Can we just not relax those for now?


---------- 8< ---------- dj.s ---------- 8< ----------
	.text
	.global	_start
_start:

	add	foo+32607,a0
	add	foo+32607,a0
	add	foo+32607,a0
	add	foo+32607,a0
	add	foo+32607,a0
	add	foo+32607,a0

        .LIL1:
        mov pc,a2
        add _GLOBAL_OFFSET_TABLE_+150-(.LIL1-.),a2

	nop

	.global	foo
foo:
	nop
---------- 8< ---------- dj.ld ---------- 8< ----------
OUTPUT_FORMAT("elf32-am33lin", "elf32-am33lin",
	      "elf32-am33lin")
OUTPUT_ARCH(mn10300)
ENTRY(_start)

SECTIONS
{
  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = 0x000000); . = 0x000000 + SIZEOF_HEADERS;
  .text           :
  {
    *(.text)
  } =0xcbcb
  . = 0x8000;
  .got            : { *(.got.plt) *(.got) }
  .data           :
  {
    *(.data)
  }
}