This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: A relocation problem in shared objects for SH
- To: binutils at sourceware dot cygnus dot com
- Subject: Re: A relocation problem in shared objects for SH
- From: kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Date: Sat, 16 Sep 2000 18:15:24 +0900
- Cc: gcc-patches at gcc dot gnu dot org
- References: <orya0shj46.fsf@guarana.lsd.ic.unicamp.br>
Alexandre Oliva <aoliva@redhat.com> wrote:
>On Sep 14, 2000, kaz Kojima <kkojima@rr.iij4u.or.jp> wrote:
>
>> We have a problem when making libc.so for sh-unknown-linux-gnu target. This
>> comes from that SH ELF uses both rela relocation and the implicit rel value
>> in memory (to support COFF, I think).
>
>Which version of the assembler are you using? I can't reproduce this
>problem with current binutils. In fact, the symptoms look very
>similar to those of the bug fixed with:
>
>2000-09-01 Alexandre Oliva <aoliva@redhat.com>
> * config/tc-sh.c (md_apply_fix): Map 32-bit relocations that
> become PC-relative to BFD_RELOC_32_PCREL. Reject 16- or 8-bit
> similar relocs.
I'm using 20000906 version of the binutils. Do you mean that there are
no incorrect relocations in the final shared object? Hmm... One point
of this bug may be that it's exposed in the case of the relocateable
object which is generated form several objects by ld -r command. In such
case, we have a R_SH_DIR32 relocation which needs both addend and implicit
reloc value in memory.
Such relocations seems correct for SH. If so, there must be a problem
in linker itself. So I think that our ugly patch for elf32-sh.c (or
something else) is still needed.
> Anyway, there is a bug, but it is in GCC. It isn't generating PIC
> code for computed goto, which glibc's vfprintf uses.
I'd like to try it. Thanks!
kaz