RE: Sparc RELA incorrect addend

RE: Sparc RELA incorrect addend

[Neil Mayes]

Hi,

I am implementing a dynamic task loader for RTEMS using a Sparc ERC32.
I have been looking in what is invloved and what I need to do in order
to relocate the code however I have seen the relocations which use an
addend are incorrect, the addend is the absolute value not the offset
from the symbol value. I have had a look at the bugs but can't find
this one.

Has anyone any knowledge of this issue?

I am using GCC version 4.2.2

Thanks,
Neil

Re: Sparc RELA incorrect addend

[Neil Mayes]

Hi,

On closer inspection it's a little worse. I have a local global
variable which is located in .data @ 0x020005AC whereas the rela tells
me its within the .text section. Symbol value == 0x02000000 (.text
vitual address) with an addend == 0x020005AC, which is actually the
absolute address. Looking through binutils I can see for a global
symbol there is the following comment:

/* To avoid generating warning messages about truncated relocations,
set the relocation's address to be the same as the start of this
section.  */

It's strange that it's not got the correct section ID as well as an
incorrect addend. If I turn it into a global global everything is OK
with addend set to zero.

This is using GNU ld (GNU Binutils) 2.18
  Supported emulations:
   elf32_sparc

Thanks,
Neil



2009/2/17 Neil Mayes <neil.mayes@googlemail.com>:
> Hi,
>
> I am implementing a dynamic task loader for RTEMS using a Sparc ERC32.
> I have been looking in what is invloved and what I need to do in order
> to relocate the code however I have seen the relocations which use an
> addend are incorrect, the addend is the absolute value not the offset
> from the symbol value. I have had a look at the bugs but can't find
> this one.
>
> Has anyone any knowledge of this issue?
>
> I am using GCC version 4.2.2
>
> Thanks,
> Neil
>

Re: Sparc RELA incorrect addend

[Ian Lance Taylor]

Neil Mayes <neil.mayes@googlemail.com> writes:

> On closer inspection it's a little worse. I have a local global
> variable which is located in .data @ 0x020005AC whereas the rela tells
> me its within the .text section. Symbol value == 0x02000000 (.text
> vitual address) with an addend == 0x020005AC, which is actually the
> absolute address. Looking through binutils I can see for a global
> symbol there is the following comment:
>
> /* To avoid generating warning messages about truncated relocations,
> set the relocation's address to be the same as the start of this
> section.  */
>
> It's strange that it's not got the correct section ID as well as an
> incorrect addend. If I turn it into a global global everything is OK
> with addend set to zero.
>
> This is using GNU ld (GNU Binutils) 2.18
>   Supported emulations:
>    elf32_sparc

You are more likely to get help on GNU binutils issues at
binutils@sourceware.org.  See http://sourceware.org/binutils .  In order
to get help on this issue, I think you will need to provide a test case.

Ian

Re: Sparc RELA incorrect addend

[Neil Mayes]

Hi Ian,

Thanks, I spotted the binutils help tonight! Appologies, newbie mistake.

Neil

2009/2/17 Ian Lance Taylor <iant@google.com>:
> Neil Mayes <neil.mayes@googlemail.com> writes:
>
>> On closer inspection it's a little worse. I have a local global
>> variable which is located in .data @ 0x020005AC whereas the rela tells
>> me its within the .text section. Symbol value == 0x02000000 (.text
>> vitual address) with an addend == 0x020005AC, which is actually the
>> absolute address. Looking through binutils I can see for a global
>> symbol there is the following comment:
>>
>> /* To avoid generating warning messages about truncated relocations,
>> set the relocation's address to be the same as the start of this
>> section.  */
>>
>> It's strange that it's not got the correct section ID as well as an
>> incorrect addend. If I turn it into a global global everything is OK
>> with addend set to zero.
>>
>> This is using GNU ld (GNU Binutils) 2.18
>>   Supported emulations:
>>    elf32_sparc
>
> You are more likely to get help on GNU binutils issues at
> binutils@sourceware.org.  See http://sourceware.org/binutils .  In order
> to get help on this issue, I think you will need to provide a test case.
>
> Ian
>