This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
R_PPC_EMB_SDA21 relocation truncated
- From: Don Lindsay <lindsayd at cisco dot com>
- To: <binutils at sources dot redhat dot com>
- Date: Mon, 11 Feb 2002 23:38:20 -0800 (PST)
- Subject: R_PPC_EMB_SDA21 relocation truncated
"-msdata=eabi" is giving me "relocation truncated" trouble with
R_PPC_EMB_SDA21 relocations. Here's a test case:
------------------------
static int initted_static = 5;
static void baz(int foo){}
int main(){
baz(initted_static);
return 0;
}
------------------------
A script which compiles-and-links the test case, with/without the flag
"-msdata=eabi". Uses a vanilla sparc-sun-solaris2.6 x powerpc GCC 3.0.3.
(I hand-define the symbol "__eabi" so that the link can be just the one .o
file, with no undefined-reference error messages. This is a cutdown, of
course.)
------------------------
#! /bin/bash
compile_and_link ()
{
powerpc-eabi-gcc $2 -c -save-temps -Wall -nostdinc -fno-builtin main.c
cp main.s main.$1.s
powerpc-eabi-ld -e main --defsym __eabi=0 main.o
}
compile_and_link std
echo "^^^^"
compile_and_link eabi -msdata=eabi
------------------------
Output of running the script, showing that -msdata=eabi causes a link
issue.
------------------------
^^^^
main.o: In function `main':
main.o(.text+0x38): relocation truncated to fit: R_PPC_EMB_SDA21 initted_static
------------------------
diff main.std.s main.eabi.s - I think it's OK.
------------------------
2c2
< .section ".data"
---
> .section ".sdata","aw"
33,34c33
< lis 9,initted_static@ha
< lwz 3,initted_static@l(9)
---
> lwz 3,initted_static@sda21(0)
------------------------
Both binutils 2.11.2 and the recent CVS sources (checkout 4feb02) show the
same problem. The link should be packing variable "initted_static" into
the ".sdata" section, which can hardly overflow.
I checked 'ld' under gdb. In bfd/elf32-ppc.c, ppc_elf_relocate_section
took the ".sdata" choice and line 3539 computed:
addend -= ( 0x8000 + 0x18100d0 + 0x4 );
which is 0xfe7e7f2c, since addend started at 0. Hmm, yeah, that doesn't
fit in a signed 16 bit field.
Suggestions?
Don