RE: gas: undefined symbol in immediate operand

["Jeremy Dexter" <jeremy dot dexter at datataker dot com dot au>]

Thanks for the replies Nick and Richard

I'm using a pre-built ARM toolchain (supplied with an embedded development
system) running on Windows under cygwin. Using a very simple test case I
get:


C:\jd\svn\can_trunk>arm-uclibc-as -a test.s -o test.o
ARM GAS  test.s                         page 1


   1                        .equ     Moo,   0x42
   2 0000 000080E3          orr      r0,r0,#moo
   3 0004 420080E3          orr      r0,r0,#Moo
   4 0008 00009FE5          ldr      r0, =bruce
   5 000c FEFFFFEA          b        freddy
   6 0010 00000000          .end
?ARM GAS  test.s                        page 2


DEFINED SYMBOLS
              test.s:1      *ABS*:00000042 Moo

UNDEFINED SYMBOLS
moo
bruce
freddy

C:\jd\svn\can_trunk>arm-uclibc-objdump -xtr test.o

test.o:     file format elf32-littlearm
test.o
architecture: arm, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 0: [APCS-32] [FPA float format]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000014  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000048  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000048  2**0
                  ALLOC
SYMBOL TABLE:
00000000 l    d  .text  00000000
00000000 l    d  .data  00000000
00000000 l    d  .bss   00000000
00000042 l       *ABS*  00000000 Moo
00000000         *UND*  00000000 moo
00000000         *UND*  00000000 bruce
00000000         *UND*  00000000 freddy


RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
0000000c R_ARM_PC24        freddy
00000010 R_ARM_ABS32       bruce

------------------

We've also tried this on a more recent PowerPC toolchain, this time running
on Linux and get a similar result:

jeff@trantor:~/prj/dt8x/bantha/Src/Bootstrap$ powerpc-eabi-as -a -mregnames
tmp.s
GAS LISTING tmp.s                       page 1


   1                    .equ MOO, 0xff000000
   2
   3                    #    .org    0x0100          # reset/NMI vector
   4                        .global _start
   5                    _start:
   6
   7 0000 3FE00000          lis     r31,moo@h
   8 0004 3FE0FF00          lis     r31,MOO@h
   9 0008 4E800020          blr
  10
  11

GAS LISTING tmp.s                       page 2


DEFINED SYMBOLS
               tmp.s:1      *ABS*:ff000000 MOO
               tmp.s:5      .text:00000000 _start

UNDEFINED SYMBOLS
moo

jeff@trantor:~/prj/dt8x/bantha/Src/Bootstrap$ powerpc-eabi-as --version
GNU assembler 060810 20060810
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `powerpc-eabi'.

----------------

The objdump output shows that the assembler hasn't created a relocation
entry for the undefined "moo" symbol, unlike the undefined "bruce" and
"freddy" symbols, but it hasn't generated an error either. This does not
seem right.

It's interesting that you got an error message using the current ARM
version, so maybe this has been fixed between 2.14 & 2.17, although I didn't
see anything in the release notes. However the PowerPC version we have very
recent and also gives no error message.

cheers

Jeremy.



-----Original Message-----
From: Nick Clifton
Sent: Thursday, 24 August 2006 8:05 pm
To: Jeremy Dexter
Cc: binutils@sourceware.org
Subject: Re: gas: undefined symbol in immediate operand


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