This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gas: undefined symbol in immediate operand
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Jeremy Dexter <jeremy dot dexter at datataker dot com dot au>
- Cc: binutils at sourceware dot org
- Date: Thu, 24 Aug 2006 09:33:06 +0100
- Subject: Re: gas: undefined symbol in immediate operand
- References: <002601c6c730$91e4b3c0$3c01a8c0@ad.datataker.com.au>
On Thu, 2006-08-24 at 04:51, Jeremy Dexter wrote:
> Hi
>
> I'm finding that if I accidentally enter an undefined symbol name as an
> *immediate* operand, then as will accept it without any warning. I've tried
> this on binutils 2.14 and 2.17 for ARM and PowerPC.
>
> For example, the ARM assembler produces the following:
>
> .equ Moo, 0x42
> 297 0148 000080E3 orr r0,r0,#moo
>
> Note the typo in the symbol name. The assembler accepts it and adds an
> undefined symbol "moo" to the object file, but the linker will not flag it
> as undefined, which I presume is because there is no valid reference to it.
> So you end up with code that ORs the value 0x00 rather than 0x42.
>
> I would have thought that the assembler is at fault here. An immediate
> operand should resolve to a *constant* - an external symbol reference should
> not be accepted here. Or am I missing something?
Not quite. On some processors an undefined symbol can be resolved by
the assembler to use a relocation (so that some external file can define
the value). So the rule in the assembler is
If there is no acceptable relocation for the missing symbol generate an
error. Otherwise, generate that relocation and the linker must raise
the error if the symbol is undefined (or can't fit the value into the
space available).
R.