Common areas and as

David Marston david at illudium.org.uk
Sun Oct 26 12:26:33 PST 2003


In message <3F9C204F.5010501 at dsvr.net> you wrote:

> See the attached file.
> 
> The code is correct as compiled by GCC 3.3.1, but if you build an 
> executable and examime the pointers in |L..20|, then you'll see 
> something weird as happened.
[snip]
> If I disassemble the resultant code, I get this:
> 
> 00008100 e59f3014 ldr   r3, &0000811c
> 00008104 e3a02003 mov   r2, #3
> 00008108 e5832000 str   r2, [r3]
> 0000810c e3a01002 mov   r1, #2
> 00008110 e59f3008 ldr   r3, &00008120
> 00008114 e5831000 str   r1, [r3]
> 00008118 e1a0f00e mov   pc, lr
> 0000811c 0000819c muleq r0, ip, r1           ; DCD |x|
> 00008120 0000827c andeq r8, r0, ip, ror r2   ; DCD |y|
> 
> Rather than pointing at the common definitions of |x| and |y|, I find 
> that 'y' points to 'main' and 'x' points to 'test5'.

Oh dear :( It seems 'as' isn't generating the right relocations for
these now that we're using the area name:

Section of DecAOF output:

At 000214: Word [00000000] displaced by symbol main
At 000210: Word [00000000] displaced by symbol test5

If I change the area definitions to something like

	AREA |C$$x|, DATA, COMMON
|x|
	EXPORT |x|
	
then I get the right relocations:

At 000214: Word [00000000] displaced by base of area C$$y
At 000210: Word [00000000] displaced by base of area C$$x

> I'm in a maze of twisty passages here and getting very confused with the 
> code in 'as'.  Does anybody have a clue about the code in 'as' or are we 
> all secretly hoping that it is bug free ?

I know it better than I knew it a couple of weeks ago, but haven't
really touched the relocations at all. I'll have a look at it unless
anyone has any bright ideas.

D
-- 
David Marston
david at illudium.org.uk




More information about the gcc mailing list