ARM xscale-wince-pe gas problems

[Alan Lehotsky <apl at alum dot mit dot edu>]

I've built an arm wince-pe gas (for use with theVisual C Embedded 3.0 tools.

I run into problems linking programs assembled with this, and I am 
beginning to think that
the problem's due to a miscommunication between gas and the MS linker.

A code fragment like

	fopen ("/users/lehotsky/data", "w")

gets emitted with code that looks like

	ldr r0, .L0
	ldr r1, .L0+4
	bl  fopen
....
     .L0: .word	__STRING.1
	 .word	__STRING.0

....
	.data
     __string.0: "/users/lehotsky/data"
     __string.1: "w"				(actually in .byte values....)

but the assembler seems to generate a relocation that looks like (according 
to objdump -r -d)

00000064 <.L0>:
   64:	00000028 	andeq	r0, r0, r8, lsr #32
			64: ARM_32	__STRING.1+0xffffffd8
   68:	00000010 	andeq	r0, r0, r0, lsl r0
			68: ARM_32	__STRING.0+0xfffffff0

Note that the data-word at label .L0 contains a 0x28, and the relocation is 
to __STRING.1-0x28
and similarly, .L0+4 contains a 0x10 with a relocation of __STRING.0-0x10

But the windows linker seems to "ignore the constant value in the 
relocation record and just
ends up generating the sum of the SYMBOL and the offset stored in the data 
word.  (Note that 0x28
and 0x10 are the respective offsets in the DATA section where the string 
values are stored.)

So, at RUNTIME, when stepping thru the program, we end up calling fopen 
with string pointer values that are 16 and 40 bytes past where the string 
parameters actually start.

Now, I don't know if this is:

	1/ Some kind of REL vs RELA problem

	2/ A mismatch between gas and the Microsoft linker

	3/ A configuration screwup on my part

	4/ Some other gas bug.....

Anybody seen anything like this?

BTW, this is the 2.9 binutils distribution...

Al Lehotsky