This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gas: undefined symbol in immediate operand
- From: Nick Clifton <nickc at redhat 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 11:04:55 +0100
- Subject: Re: gas: undefined symbol in immediate operand
- References: <002601c6c730$91e4b3c0$3c01a8c0@ad.datataker.com.au>
Hi Jeremy,
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.
Are you sure about this ? I just tried an arm-eabi toolchain built from
the 2.17 sources and using your test case:
.equ Moo, 0x42
orr r0,r0,#moo
I received this error message:
jim.s: Assembler messages:
jim.s:5: Error: undefined symbol moo used as an immediate value
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.
No if the linker does behave this way then it is a bug. Assuming that
the assembler does pass the reference to the undefined "moo" symbol on
to the linker, then the linker should complain about it. The only
reason it would not is if the reference to the symbol is in a section of
code that is being discarded and not included in the final executable.
Can you put together a full test case to demonstrate the problem,
including specifying which toolchain(s) you use ?
Cheers
Nick