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: Sun, 17 Sep 2000 10:23:58 +0900
- Cc: gcc-patches at gcc dot gnu dot org
- References: <ork8ccdzm4.fsf@guarana.lsd.ic.unicamp.br>
Alexandre Oliva <aoliva@redhat.com> wrote:
>>> So I think that our ugly patch for elf32-sh.c (or something else) is
>>> still needed.
>
>> Yep. I'll keep looking for something else for a while :-)
>
> Here's the ``something else'' I've come up with. It fixes the
> relocatable link, so that it doesn't generate relocations with both
> an in-place value and an addend. I've tried to relocate a lot of PIC
> and non-PIC object files, and it always did The Right Thing (TM), so I
> guess this is the way to go. Ok to install?
I've just tested this in libc and it works. Thank you for The Right
Thing (TM)!
BTW, readelf displays the garbage value for the addend of the generated
R_SH_RELATIVE relocation. We should clear such addend field, shouldn't
we?
--- /cvs/src/bfd/elf32-sh.c Sun Sep 17 08:40:07 2000
+++ elf32-sh.c Sun Sep 17 09:50:54 2000
@@ -3124,7 +3124,7 @@ sh_elf_relocate_section (output_bfd, inf
{
relocate = true;
outrel.r_info = ELF32_R_INFO (0, R_SH_RELATIVE);
- outrel.r_addend = relocation + rel->r_addend;
+ outrel.r_addend = 0;
}
else
{
kaz