This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] PIC support for SH
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: [PATCH] PIC support for SH
- From: NIIBE Yutaka <gniibe at chroot dot org>
- Date: Fri, 08 Sep 2000 10:35:58 +0900
- Cc: kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, binutils at sources dot redhat dot com
- References: <200008290305.MAA22429@rr.iij4u.or.jp><or66ohil7i.fsf@guarana.lsd.ic.unicamp.br><or1yz5ik5p.fsf@guarana.lsd.ic.unicamp.br>
Alexandre Oliva wrote:
> from Alexandre Oliva <aoliva@redhat.com>
>
> * sh.h (R_SH_GOT32, R_SH_PLT32, R_SH_COPY, R_SH_GLOB_DAT,
> R_SH_JMP_SLOT, R_SH_RELATIVE, R_SH_GOTOFF, R_SH_GOTPC): New relocs.
> (R_SH_FIRST_INVALID_RELOC): Adjust.
>
> Index: include/elf/sh.h
> ===================================================================
> RCS file: /cvs/src/src/include/elf/sh.h,v
> retrieving revision 1.4
> diff -u -p -r1.4 sh.h
> --- include/elf/sh.h 2000/06/07 03:43:33 1.4
> +++ include/elf/sh.h 2000/08/31 14:14:39
> @@ -63,7 +63,15 @@ START_RELOC_NUMBERS (elf_sh_reloc_type)
> RELOC_NUMBER (R_SH_DIR8BP, 7)
> RELOC_NUMBER (R_SH_DIR8W, 8)
> RELOC_NUMBER (R_SH_DIR8L, 9)
> - FAKE_RELOC (R_SH_FIRST_INVALID_RELOC, 10)
> + RELOC_NUMBER (R_SH_GOT32, 10)
> + RELOC_NUMBER (R_SH_PLT32, 11)
> + RELOC_NUMBER (R_SH_COPY, 12)
> + RELOC_NUMBER (R_SH_GLOB_DAT, 13)
> + RELOC_NUMBER (R_SH_JMP_SLOT, 14)
> + RELOC_NUMBER (R_SH_RELATIVE, 15)
> + RELOC_NUMBER (R_SH_GOTOFF, 16)
> + RELOC_NUMBER (R_SH_GOTPC, 17)
> + FAKE_RELOC (R_SH_FIRST_INVALID_RELOC, 18)
> FAKE_RELOC (R_SH_LAST_INVALID_RELOC, 24)
> RELOC_NUMBER (R_SH_SWITCH16, 25)
> RELOC_NUMBER (R_SH_SWITCH32, 26)
Sorry for my late response, but could I ask you a question?
Is there any reason for the value 10--17 here? In our implementation,
we use the assigned number (by Hitachi) 160-167 for this purpose.
I've heard that other vendor's tool already uses 10--17 for different
purpose. So, GNU tool may break the compatibility here, which we should
avoid.
It's OK for us (Linux port for SH) to re-compile all the binaries now
as it's still young. But I'm afraid of already distributed other
vendor's binaries other than Linux.
--