bug in gas/read.c:s_space ?

[Nick Clifton]

Hi Geoff,

: It seems to me that the error checking in the included snippet of
: s_space() is incorrect since the error is only reported if exp (which
: is the size expression) is non-constant.  This leads to weird behaivor
: if someone mistakenly writes
: 
: 	.space	0x100, a

[Ian has already answered this, but I will chip in with my 2 cents
worth.]

What this does is to generate 0x100 references to the symbol 'a'.

For example if you had:

    nop
    .space 4, 0xff
    nop

in your assembler source you would get 4 bytes filled with 0xff:

   0:   e1a00000        nop                     (mov r0,r0)
   4:   ffffffff        swinv   0x00ffffff
   8:   e1a00000        nop                     (mov r0,r0)

[I am using the ARM assembler here, since that is my favorite, but
you would get the same effect with any instruction set].  If on the
other hand your source looked like this:

    nop
    .space 4, my_label
    nop

you would get (using 'objdump -dr' to see the relocations and disassembly):

   0:   e1a00000        nop                     (mov r0,r0)
   4:   00000000        andeq   r0, r0, r0
                        4: R_ARM_ABS32  my_label
                        5: R_ARM_ABS32  my_label
                        6: R_ARM_ABS32  my_label
                        7: R_ARM_ABS32  my_label
   8:   e1000000        tst     r0, r0

ie four references to the label 'my_label' each of which occupies one
byte, even though the relocation used is a 32 bit relocation.  This is
almost certainly not what the programmer intended.

What was probably intended was the resolution of 'my_label' to some
known constant, like this:

    .set apdding, 0xff
    nop
    .space 4, padding
    nop

which produces the same effect as '.space 4, 0xff'.

: I would send a patch, but I don't really understand the intention of
: the code in the else branch.

The code in the else branch is handle the case where the symbol is
defined AFTER the space directive, like this:

    nop
    .space 4, padding
    nop
    .set apdding, 0xff

The code in the else branch makes this do the right thimg (tm).

This is why no warning is issued in the else branch.  The code
generates the references to the symbol prodived in the .space
directive, but it cannot tell if this symbol will be resolved to some
constant before the end of the assemble process.

It might be feasable to issue a warning message in this case, saying
that the symbol is being used before it is defined.  Alternatively the
target specific code in the various backends could be extended to
notice when it is generating unaligned relocs, but other than that it
is basically up to the assembly language programmer to know what they
are doing.

Cheers
	Nick