gcc 3.3.3 and interworking

[Dave Korn]

> -----Original Message-----
> From: Dave Murphy  
> Sent: 14 April 2004 22:19

> apologies for being a complete pain, further research shows 
> that the problem
> is something to do with the address of the text section. In 
> the system I'm
> building the cross compiler for this is 0x08000000. Bizarrely 
> it seems that
> any address for the text section greater than 0x01fffc0c 
> produces the error
> (bit of an odd number really)

Well, that makes me want to guess that your .text section is currently
exactly (0x02000000 - 0x01fffc0c) = 0x3f4 bytes big.  Am I close?

And then I'd start to say, hmm, well, overflowing at 0x02000000 means 26
significant bits, minus the two on the end which I guess are always zeros,
which makes me wonder if there are any ARM instructions that have a 24-bit
field for a pc-relative offset, and about R_ARM_PC24.

We may be looking at something like the ppc long call issue here, with
presumably pretty much the same answer - i.e. gcc needs to be told to load
the function address into a register and call it indirectly.

Or perhaps the assembler is issuing the wrong reloc type: emitting a 32 bit
reloc against an insn with a 24-bit operand field.

Or perhaps when the code for handling all those reloc types was refactored
into one there somehow became a confusion between R_ARM_PC24 and
R_ARM_PLT32.

Hmm.  Looking at line 555 of config/arm/lib1funcs.asm I see

	FUNC_END divsi3

which comes from a macro

.macro FUNC_END name
Ldiv0:
#ifdef __thumb__
	THUMB_LDIV0
#else
	ARM_LDIV0
#endif
	SIZE (__\name)	
.endm

which refers to these definitions when interworking:

#else
# ifdef __THUMB_INTERWORK__
#  define RET		bx	lr
#  define RETc(x)	bx##x	lr
.macro THUMB_LDIV0
Ldiv0:
	push	{ lr }
	bl	SYM (__div0)
	mov	r0, #0			@ About as wrong as it could be.
	pop	{ r1 }
	bx	r1
.endm
.macro ARM_LDIV0
Ldiv0:
	str	lr, [sp, #-4]!
	bl	SYM (__div0) __PLT__
	mov	r0, #0			@ About as wrong as it could be.
	ldr	lr, [sp], #4
	bx	lr
.endm	
# else


So, that bl SYM (__div0) __PLT__ must be the insn that's getting the reloc
issued against it.

Hmm, is this one of those intra-section
difference-of-two-symbols-requires-the-reloc-to-be-converted-to-pcrel
problems, where the conversion to pcrel gets done by the generic layer
behind the backend's back, perhaps?

All this is without doing any experiments to attempt to confirm any of these
possibilities yet, so it's all speculative; I'm really just hoping that many
heads will be better than one and extra ideas to consider can only help.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....