This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: mn10300: PCREL16 reloc question
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 13 May 2008 02:14:50 -0300
- Subject: Re: mn10300: PCREL16 reloc question
- References: <200712140225.lBE2PfvQ027081@greed.delorie.com>
Sorry that it took me so long to respond.
On Dec 14, 2007, DJ Delorie <dj@redhat.com> wrote:
> In elf-m10300.c mn10300_elf_final_link_relocate() for the
> R_MN10300_PCREL16 case at line 1221, we use a range that's twice as
> big as I'd expect:
> if ((long) value > 0xffff || (long) value < -0x10000)
> return bfd_reloc_overflow;
> Are there any real cases where we'd need this range, and not the usual
> -0x8000..0x7fff range?
I vaguely remember having wondered about this myself very long ago. I
think back then I thought it might have to do with supporting literal
displacements or some such, but I don't see that this makes much sense
now, since literal displacements wouldn't generate a relocation in the
first place. It appears to be safe enough to nuke, since there aren't
any operand types defined with 1-bit shifts in opcodes/m10300-opc.c,
nor are there relocations that expect this in include/elf/mn10300.h.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ÂSÃ Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}