This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
mn10300 relaxation vs got
- From: DJ Delorie <dj at redhat dot com>
- To: binutils at sourceware dot org
- Date: Tue, 11 Jul 2006 21:15:59 -0400
- Subject: mn10300 relaxation vs got
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)
}
}