This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

"Unsupported Relocation Error" Compiling Thumb Code


Hi Folks,
I'm cross compiling using arm-elf-gcc on a linux host and have a 
problem. I'm not sure if there is a compiler bug or I'm not using the 
correct command line options for gcc, but I the results are as described 
below.
I've tried using both gcc 3.0.1 and 3.0.2 (both producing the same 
results) and I have a simple multiple inheritance relationship viz:

class A
{
public:
              A();
     virtual ~A();
     virtual void F();
};


class B
{
public:
              B();
     virtual ~B();
     virtual void F();
};


class C : public A, public B
{
public:
              C();
     virtual ~C();
     void F();
};


I then have a very simply entry function which instatiates an object of 
type C and uses pointers to A,B and C types to point to this object.

At the link stage I get an "unsupported relocation error"

a.o: In function `non-virtual thunk to C::~C()':
a.o(.gnu.linkonce.t._ZThn4_N1CD1Ev+0x2): internal error: unsupported 
relocation error
a.o: In function `non-virtual thunk to C::~C()':
a.o(.gnu.linkonce.t._ZThn4_N1CD0Ev+0x2): internal error: unsupported 
relocation error
a.o: In function `non-virtual thunk to C::F()':
a.o(.gnu.linkonce.t._ZThn4_N1C1FEv+0x2): internal error: unsupported 
relocation error
ia_rX.o

I've no idea what "unsupported relocation error" means but i think I can 
guess by examining the (broken) image. When I examine the disassembled 
output I have observed that the thunks for C's destructors and F 
operations are corrupt, with instructions of the form:

00001ff4 <_ZThn4_N1C1FEv>:
     1ff4:	3804      	sub	r0, #4
     1ff6:	e7fe      	b	1ff6 <_ZThn4_N1C1FEv+0x2>

00001ff8 <_ZN1C1FEv>:
     1ff8:	4770      	bx	lr
	...

Clearly, the C::F() thunk will never call the F function because the 
branch instruction e7fe is a halt ! I don't understand why the 
compiler/linker didn't produce a "b 1ff9" which is well within the range 
of the branch instruction in thumb mode.


Compiling code to run in Arm mode produces the following:

00002ca0 <_ZThn4_N1C1FEv>:
     2ca0:	e2400004 	sub	r0, r0, #4	; 0x4
     2ca4:	eaffffff 	b	2ca8 <_ZN1C1FEv>

00002ca8 <_ZN1C1FEv>:
     2ca8:	e1a0f00e 	mov	pc, lr


and the C::F() thunk correctly calls the C::F() operation.


Command line options compiling the thumb code are:
arm-elf-g++ -pipe -Wall  -Wmissing-declarations -Wmissing-prototypes 
-Wstrict-prototypes -Wpointer-arith -mlittle-endian -mno-sched-prolog 
-fomit-frame-pointer -fno-exceptions -fno-rtti -fbuiltin -mcpu=arm9 
-mthumb -O2 -finline-functions -finline-limit=125 -c src/a.cxx -o a.o

and linking are:
arm-elf-g++ -o gcc_tests -g -Wl,--gc-sections -nostdlib -Wl,--verbose 
-Wl,-EL -Wl,-N -u _ENTRY  a.o -lSysLib .....

I've tried removing inlining options and having the class operations 
inlined and non-inlined, but nothing appears to resolve the error.

Has anyone seen this sort of problem producing thumb code ?

Are my command line options for gcc correct ?


Thanks,
Andy Parker

PS - Anyone successfully built cross-gcc v3.0.3 for arm-elf hosted under 
linux ? Mine's broken !

-- 
Andy Parker                       Oxford Semiconductor Ltd
Tel: +44 (0) 1235 824 944         25 Milton Park, Abingdon,
Fax: +44 (0) 1235 821 141         Oxfordshire. OX14 4SH
andy.parker@oxsemi.com            http://www.oxsemi.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]